Taschenrechner funktioniert beim weiterrechnen nicht richtig

Knuddlbaer

pascal2009 schrieb:

Nun sind deine Beispiel so wie sie sind zwar völlig in Ordnung, aber ich muß einwenden, wenn man statt:
if (!Bedingung1)
	return;
if (!Bedingung2)
	return;
if (!Bedingung3)
	return;
<code>
dessen schreibt:
if (!Bedingung1) 
else if (!Bedingung2)
else if (!Bedingung3)
else <code> // ist else 3
else //else 2
else // else 1

sollte man die Grundlagen noch mal angehen. Der Code macht nicht das gleiche!

ich nicht sehen kann, daß die Performance schlechter wäre als mit den Returns, obwohl hier kein einziges return vorkommt.

Returns beinhalten auch, daß bei Programmänderungen, wo man vergißt, sie wieder hinzuzufügen, der Code möglicherweise durchrutscht.

Bei saubererer else-Verschachtelung rutscht da nie was durch.

Dein Code entspricht nicht der flachen Vorgabe. Hier solltest Du erst einmal wirklich nachdenken bevor Du Deine Aussagen so stehen lässt.

Ob man Schachtelt oder nicht ist durchaus eine Stielfrage, allerdings kann man bei einer flachen Variante den Austiegspunkt sofort erkennen. Verschachtelungen müssen komplett gelesen werden.

Schau Dir die Beispiele. Ich denke bei der Flachen wird sofort klar was passiert. Bei der Verschachtelung hast du schon völlig falsch angesetzt. [stichel}(Doch nicht so einfach? ;o)[/stichel}

pascal2009

ALso bei dem Code kann ich nicht helfen, dafür reichen meine C# Kenntnisse nicht aus!

Einen Taschenrechner in C würde ich als ineinandergeschachtelte Schleifen programmieren, und die Auswertung auf Funktionen (in C# Methoden) auslagern, das wäre ein sehr kurzer Code, und nicht sequentiell, sondern geschachtelt. Das wäre nicht mal ein Drittel von dem Code, den ich bis jetzt von dir zu dem taschenrechner gesehen habe.

Tut mir leid, aber zu dem C# Konstrukt kann ich keinen Kommentar abgeben. Ich hab nur den Verdacht, daß man das viel, viel kürzer codieren könnte.
Ein Taschenrechner ist eine ganz banale Angelegenheit, der rechtfertigt doch nicht soviel Code, war mein erster Gedanke.

Wie gesagt aber C# ist noch zu frisch. Vielleicht helfen dir andere weiter.

Pascal

pascal2009

Knuddlbaer schrieb:

Ob man Schachtelt oder nicht ist durchaus eine Stielfrage, allerdings kann man bei einer flachen Variante den Austiegspunkt sofort erkennen. Verschachtelungen müssen komplett gelesen werden.

Schau Dir die Beispiele. Ich denke bei der Flachen wird sofort klar was passiert. Bei der Verschachtelung hast du schon völlig falsch angesetzt. [stichel}(Doch nicht so einfach? ;o)[/stichel}

Wenn du mit if und return arbeitest, eine flache Struktur, wie du sagst, nur der Übersicht wegen, hast du eine Struktur, die eigentlich keine Verzweigung rechtfertigt. Das ist entweder eine solche Struktur:

int c=(a>=b)? a:b;

die du unnötigerweise in eine if_Abfrage bringst, oder es ist eine switch-artige struktur, wofür du als formale Hülse eine If-Abfrage bringst.

Das leuchtet mir alles nicht ein, daß sowas sauber sein soll. Deine Art von den flachen if-returns könnte man zuvor in einen int-Wert umformen und als switch laufen lassen, das sind keine Verzweigungen, sondern das ist IF-Pseudo-Code. Wenn er so gewollt ist ok, trotzdem SCHLECHTER STIL.

Die ganzen Verzweigungen stehen ja immer am Ende der Vorüberlegung. Man kann alle Verzweigungen bevor es soweit kommt auch immer anders überlegen.

Es gibt dutzende Möglichkeiten, tiefe if-Verschachtelungen (da sind wir uns einig, daß die n icht einfach zu lesen bzw. zu handeln sind) zu vermeiden,

tiefe if-Verschachtelungen sind eigentlich der Beweis, daß das Problem

IM VORFELD

schlecht überlegt wurde.

Und sich dann mit Pseudy-Ifs a la

if (bedingung) ...
return

rauszuretten, läßt sich meiner Meinung nach in jedem Einzelfall beweisen, daß man das ohne return besser lösen könnte, aber nicht am Ende, sondern ausgehend von der Anfangsüberlegung. Tiefe Verschachtelungen sind möglicherweise ein Zeichen von falscher Organisation der Programmlogik, da trifft es dann, was zuvor versäumt wurde (mehr Methoden und Funktionen), alles aufeinander.

Return ist <taktisch> für die schnelle Nummer, ein Ausräumer, Return ist <strategisch> kein guter Beweis für tiefsitzende Logik, sondern eher für versäumte Logik im Vorfeld. Strategisch gut positionierte Programmlogik benötigt keine tief verschachtelten IF-Schleifen.

Pascal

Soviel Code wollte ich eigentlich auch nicht machen.

Aber die ganzen if Bedingungen.

Jede Zahl ist bei mir ca 50 Zeilen lang.
Aber es wiederholt sich recht viel.

Knuddlbaer

http://www.c-plusplus.net/forum/viewtopic-var-p-is-1657617.html#1657617

pascal2009

Wandernder Mongole schrieb:

Soviel Code wollte ich eigentlich auch nicht machen.

Aber die ganzen if Bedingungen.

Jede Zahl ist bei mir ca 50 Zeilen lang.
Aber es wiederholt sich recht viel.

Ich hab keine zeit, mich damit wirklich zu beschäftigen.

Wenn ich aber vor meinem geistigen Auge einen Taschenrechner sehe, sehe ich 3-4 ineinander verschachtelte Schleifen. Die äußere läuft auf Abbruchbedingung = Taschenrechner aus, die zweite läuft auf die gewählte rechenoperation, die dritte liest die Zahlenwerte von der ersten Nummer ein, und anschließend die Zahlenwerte von der zweiten Nummer. Diese sind sequentiell innheralb einer Schleife unterzubringen! Da die auf einer Ebene laufen, dürfen die nicht verschachtelt werden! Nur für besondere Rechenoperationen wär vielleicht noch Schleife 4 nötig, wie wissenschaftlicher Taschenrechner. Egal wieviele Ziffern eingegeben werden, es gibt keine Programmzeile mehr bei 5 Ziffern oder 5000 Ziffern!

Bei einem ersten Blick auf deinen Code habe ich den Verdacht, du hängst die Eingabefelder sequentiell aneinander, ohne sie zu schachteln. Also mit 10 Nummern hast du mehr Code als mit 3 Nummern.

Wenn es so wäre, wäre das nicht nur kein guter, sondern ein saumäßiger Algorithmus, um einen so banalen Sachverhalt wie einen taschenrechner zu programmieren. Du solltest wohl eher, wenn es so wäre, deine Programmstruktur völlig umkrempeln anstatt dieses Problem mit der if-Verzweigung überhaupt noch weiter zu beachten. Wenn du das vernünftig programmierst, entfällt das als gegenstandslos.

Anders gesagt, wenn das so wäre, hättest du kein Problem mit dem if, sondern das if wäre ein Hinweis auf falschen Algorithmus. Insbesondere wenn es so wäre, wäre das Arbeiten mit Notstopfen return nicht nur schlimm, sondern verheerend.

Pascal

Troll - Alarm
Sowas hat uns noch gefehlt...