Was ist schönerer Code - return Wert alleinstehend oder mit Berechnung?

[randa]

Version eins, wegen dem +=, ansonsten Version zwei.

Ich schreibe nie += oder = in einem Verschachtelten Ausdruck oder in einem if, das sind manchmal böse Stolperfallen nicht nur weil es für die meisten unerwartet kommt, sondern auch weil eine Zuweisung wichtig genug ist dass sie explizit geschehen sollte.

Letzenendes gibt es aber keinen Ersatz für Aufmerksamkeit. Man muss halt sorgfältig lesen, das erspart einem niemand. Aus dem Grund sind prinzipiell die meisten Stile gleichwertig.

[camper]

hustbaer schrieb:

double durchschnitt(double a, double b) 
{
    double const result = (a + b) / 2;    // Besser debugbar
    return result;
}

Wird Zeit, dass jemand den Debuggern mal beibringt, zwischen Wertberechnung und tatsächlichem return noch eine Unterbrechung zuzulassen.

[camper]

hustbaer schrieb:

Was ich gar nicht mag ist Variablen zu ändern wenn man nicht muss (SeppJ's durchschnitt /= 2 Variante).
SSA ist nicht nur für Code-Generatoren gut

In den Fällen, wo man nicht muss, kriegt die Variable einfach eine neue Version (problematisch wird es ja erst, wenn die Variable nicht aliasfrei ist, und man im folgenden nicht statisch bestimmen kann, auf welche Version zugegriffen wird). Ich sehe nicht, wie SSA da Schwierigkeiten bekommt.

[Kellerautomat]

ich finde die return += variante am besten, wuerde aber die unnoetigen klammern weglassen.

[cooky451]

camper schrieb:

Wird Zeit, dass jemand den Debuggern mal beibringt, zwischen Wertberechnung und tatsächlichem return noch eine Unterbrechung zuzulassen.

Nun ja, bei VS wird einem angezeigt welchen Wert die Funktion zurückgegeben hat... solche Umwege sind da also streng genommen unnötig.^^

[camper]

cooky451 schrieb:

camper schrieb:

Wird Zeit, dass jemand den Debuggern mal beibringt, zwischen Wertberechnung und tatsächlichem return noch eine Unterbrechung zuzulassen.

Nun ja, bei VS wird einem angezeigt welchen Wert die Funktion zurückgegeben hat... solche Umwege sind da also streng genommen unnötig.^^

Wenn der Wert aber falsch ist, bekomme ich so nicht mehr heraus, warum.

[hustbaer]

camper schrieb:

Ich sehe nicht, wie SSA da Schwierigkeiten bekommt.

Das SSA vom Compiler/Code-Generator bekommt gar keine Schwierigkeiten.

Ich meinte: das was SSA ausmacht ist auch sehr angenehm beim Lesen von Code. Also wenn man seinen C++ Code so schreibt dass man alles "const" macht, weil man immer nur initialisiert und den Wert dann nie ändert.

Natürlich muss man es damit nicht übertreiben. Also ich schreib' jetzt deswegen nicht alles um nur damit ich Schleifen oder so vermeide.

Nur bevor ich

int x = ...;
x += 123;
x = blah(x);
...

schreibe, geb ich lieber jedem Zwischenergebnis einen neuen Namen.
Weil's beim Code Lesen dadurch viel einfacher zu sehen ist was abgeht.

[hustbaer]

cooky451 schrieb:

camper schrieb:

Wird Zeit, dass jemand den Debuggern mal beibringt, zwischen Wertberechnung und tatsächlichem return noch eine Unterbrechung zuzulassen.

Nun ja, bei VS wird einem angezeigt welchen Wert die Funktion zurückgegeben hat... solche Umwege sind da also streng genommen unnötig.^^

Kann man das irgendwo abdrehen? Weil ich bekomm' das irgendwie nimmer angezeigt. Ich kann mich erinnern es schon gesehen zu haben, aber hab' das in den letzten Jahren öfter mal vergeblich gesucht.

[Fytch]

hustbaer schrieb:

Kann man das irgendwo abdrehen? Weil ich bekomm' das irgendwie nimmer angezeigt. Ich kann mich erinnern es schon gesehen zu haben, aber hab' das in den letzten Jahren öfter mal vergeblich gesucht.

Ob und wie man es ein- / ausschalten kann weiss ich nicht. Jedoch ist der Rückgabewert nur in Lokal und in Auto zu sehen, nicht in "Überwachen" (solltest du permanent das offen haben) und nur wenn man durch die Funktion durchsteppt (wenn man die Anweisung mit dem Funktionsaufruf mit dem Prozedurschritt F10 überspringt wird bei mir auch nichts angezeigt; wenn ich nach dem Return-Statement einen Schritt mache, dann hingegen schon).

[hustbaer]

Hm.
Gerade probiert, und funktioniert.
Komisch.
Ich hab in gesagten Fällen nämlich ganz sicher in "Autos" geguckt, daran kann ich mich noch gut erinnern. Weil's halt irgendwie logisch ist dass es in "Autos" angezeigt wird - sonst passt's ja nicht wirklich wo rein.

[SeppJ]

Kellerautomat schrieb:

ich finde die return += variante am besten, wuerde aber die unnoetigen klammern weglassen.

*Schauder*

Wer Nebeneffekte in Ausdrücken versteckt, der macht auch ... keine Ahnung, such dir was aus, dass du nicht leiden kannst

Ich vermeide sogar Inkremente in Ausdrücken (außer als alleinstehender Ausdruck natürlich), außer es geht um irgendwelche Angebereien, wer das kürzeste strcpy schreiben kann.

[volkard]

SeppJ schrieb:

Ich vermeide sogar Inkremente in Ausdrücken (außer als alleinstehender Ausdruck natürlich), außer es geht um irgendwelche Angebereien, wer das kürzeste strcpy schreiben kann.

Und außer in *out++= (in C) hoffe ich mal.

[Syntaktischer Zucker]

SeppJ schrieb:

Wenn das endwert wirklich verändert werden soll, dann auf jeden Fall das Erste. Soll das wirklich += sein?

Ja, das += habe ich für das Beispiel eingebaut, weil man ja auch ansonsten einfach:

// Vorheriger Bereich der Funktion
  ...
  return (x + (y - (bla % 10 - ext)/3));
}

hätte schreiben können.

Also musste ich dafür sorgen, dass am Ende im Prinzip der Wert einer Variable zurückgegeben werden soll und die Notwendigkeit der Variable bringt man eben dadurch zum Ausdruck, in dem man sie mit der Berechnung verrechnet.

Oder hättest du eine Berechnung erst in eine Variable gespeichert, um sie erst dann zurückzuliefern?
Also so:

// Vorheriger Bereich der Funktion
  ...
  double endwert = (x + (y - (bla % 10 - ext)/3));
  return endwert;
}

Anstatt += wäre natürlich auch:

endwert = endwert +  x + (y - (bla % 10 - ext)/3);

gegangen, aber das war mir dann zu viel Schreibarbeit.

[SeppJ]

volkard schrieb:

SeppJ schrieb:

Ich vermeide sogar Inkremente in Ausdrücken (außer als alleinstehender Ausdruck natürlich), außer es geht um irgendwelche Angebereien, wer das kürzeste strcpy schreiben kann.

Und außer in *out++= (in C) hoffe ich mal.

Ja, das ist halt so ein typischer strcpy-Hack. Wobei ein durch ein Gleichheitszeichen abgetrennter Ausdruck schon fast als Alleinstehend zählen kann. Da ist es in Ordnung, so etwas auf einer Seite stehen zu haben^*.

^*: Und dann wird sich natürlich prompt irgendjemand finden, der *out++ = *out + 1 schreibt und mich zitiert, dass ich so etwas gutgeheißen hätte

--------------------
@Syntaktischer Zucker: Ich weiß nicht, ob du wirklich verstanden hast, wieso sich alle an dem += stören: Es geht da drum, dass durch das += im return eben die wichtige Information untergeht, dass das die Variable endwert selber noch verändert wird. Dies ist eine sehr wichtige Information (sonst würde man es ja nicht tun) und zudem sehr ungewöhnlich (wann hat man schon nicht-lokale Variablen zur Speicherung eines Ergebnisses?). Da sollte man unbedingt Wert darauf legen, dass dieser Vorgang auch gut sichtbar ist und den nicht in einer Rechnung verstecken.

[Syntaktischer Zucker]

hustbaer schrieb:

Nur bevor ich

int x = ...;
x += 123;
x = blah(x);
...

schreibe, geb ich lieber jedem Zwischenergebnis einen neuen Namen.
Weil's beim Code Lesen dadurch viel einfacher zu sehen ist was abgeht.

Dann steigt aber auch der Speicherverbrauch.
Und die Performance leidet ebenfalls darunter.

Bei Variablen, die im Prinzip zum rechnen gleich weiterbenutzt werden, kann der Compiler z.B. dafür sorgen, das die in einem Register bleiben und das ist eben schneller, als wenn man den Wert wieder aus einer Speicheradresse holen müsste.
Selbst mit 2nd Level Cache sind die Register schneller und seit AMD64 gibt's ja genug davon.

[SeppJ]

Syntaktischer Zucker schrieb:

hustbaer schrieb:

Nur bevor ich

int x = ...;
x += 123;
x = blah(x);
...

schreibe, geb ich lieber jedem Zwischenergebnis einen neuen Namen.
Weil's beim Code Lesen dadurch viel einfacher zu sehen ist was abgeht.

Dann steigt aber auch der Speicherverbrauch.
Und die Performance leidet ebenfalls darunter.

Bei Variablen, die im Prinzip zum rechnen gleich weiterbenutzt werden, kann der Compiler z.B. dafür sorgen, das die in einem Register bleiben und das ist eben schneller, als wenn man den Wert wieder aus einer Speicheradresse holen müsste.
Selbst mit 2nd Level Cache sind die Register schneller und seit AMD64 gibt's ja genug davon.

Und das kann der Compiler im anderen Fall warum nicht?

Ich habe übrigens noch eine Antwort auf deinen vorherigen Post in meinen vorherigen Post reineditiert (da ich ein Doppelposting vermeiden wollte), während du anscheindend schon wieder geantwortet hast.

[camper]

Syntaktischer Zucker schrieb:

hustbaer schrieb:

Nur bevor ich

int x = ...;
x += 123;
x = blah(x);
...

schreibe, geb ich lieber jedem Zwischenergebnis einen neuen Namen.
Weil's beim Code Lesen dadurch viel einfacher zu sehen ist was abgeht.

Dann steigt aber auch der Speicherverbrauch.
Und die Performance leidet ebenfalls darunter.

Ach was. Wir sind doch nicht in der Compilersteinzeit. Gerade wenn man an SSA denkt, wird schnell klar, dass es für die Performance ziemlich egal ist, ob eine neue Variable eingeführt oder eine alte wiederverwendet wird.

[Syntaktischer Zucker]

SeppJ schrieb:

Ich habe übrigens noch eine Antwort auf deinen vorherigen Post in meinen vorherigen Post reineditiert (da ich ein Doppelposting vermeiden wollte), während du anscheindend schon wieder geantwortet hast.

Hab's jetzt gelesen.
Also mir würde das += auffallen.

[Marthog]

Ich bevorzuge einzeilige Funktionen mit direktem Rueckgabewert, solange die Zeile nicht zu lang wird.
Das liegt daran, dass ich funktionale Sprachen sehr gerne mag und es da nur den Rueckgabewert gibt und gar keine anderen Moeglichkeiten, ausser man definiert sich mit where oder let irgendwelche zusaetzlichen Variablen hin.
Ansonsten finde ich neue Variablen verwenden schoener, weil eine Variable eine feste Bedeutung haben sollte und sich die nicht veraendern sollte.

[hustbaer]

Syntaktischer Zucker schrieb:

Also mir würde das += auffallen.

Es ist nicht übersichtlich.
Es irritiert.
Mag sein dass es "auffällt", aber "auffällig" ist nicht unbedingt gut beim Lesen von Code. Übersichtlich ist besser.