ist break wirklich schlechter programmierstil?
-
alsoso weit ich das versteh wird die funktion verlassen und nachdem alles ausgefuehrt wurde wird an der stelle weitergemacht
so ist das doch allg bei funktionen
aber meine frage ist ja ob dasd break wirklich schlecht ist da?
ich finde den umweg ueber einen bool nicht wirklich besser
-
CarstenJ schrieb:
weil die Funktion ja quasi nach dem ersten Aufruf verlassen und dann mit den neuen Werten aufgerufen wird. Also wird doch alles, was nach dem ersten Aufruf der Funktion steht, ignoriert?! Oder hab ich was übersehen?
Wenn da jetzt return fermat_zerlegung(... stünde, hättest du recht. Aber so ist das ein normaler Funktionsaufruf, der auch irgendwann mal zurückkommt, falls keine Endlosrekursion vorliegt. Und dann geht es dahinter weiter.
-
CarstenJ schrieb:
Oder hab ich was übersehen?
Also nach deinem Verständnis hast du nichts übersehen, aber du hast das mit den Rekursionen nicht ganz verstanden
. Die Funktion geht nach einem Selbstaufruf selbstverständlich weiter falls der Selbstaufruf irgendwann terminiert (wovon ich ausgehe, denn sonst wäre es sicher ein Programmfehler).
-
ich finde break deswegen auch am sinnvollsten
-
du könntest auch gleich return schreiben, da b ja sowieso auf false gesetzt wird und der if-Teil dann sowieso nicht betreten wird...
-
Walli schrieb:
CarstenJ schrieb:
Oder hab ich was übersehen?
Also nach deinem Verständnis hast du nichts übersehen, aber du hast das mit den Rekursionen nicht ganz verstanden
. Die Funktion geht nach einem Selbstaufruf selbstverständlich weiter falls der Selbstaufruf irgendwann terminiert (wovon ich ausgehe, denn sonst wäre es sicher ein Programmfehler).Jo, mein Fehler. Sorry.
-
Unser Prof hat damals gesagt das break nich ganz so in Dijkstra (schlagt mich wenn ichs falsch schreib) Schema für strukturierte Programmierung war passt (ich hoffe ihr wisst jetz was ich mein^^).
Wieso es schlechter Stil sein soll weiss ich allerdings auch nicht.. man sieht ja, die schleife wird halt genau _hier_ verlassen, er springt ja nicht irgendwie wild "in der Gegend" herum
ansonsten führen wie immer viele Wege zum Ziel ...
-
Dommel schrieb:
du könntest auch gleich return schreiben, da b ja sowieso auf false gesetzt wird und der if-Teil dann sowieso nicht betreten wird...
ja stimmt schon
aber dann muesste man in return 2 funktionsaufruse uebergeben(was ja nicht geht)
oder die funktion muesste dann 2 werte aufnehemn koennen ,dann kann ich mir rekrusion auch sparen
die fand mein prof allerdings ganz toll auch wenn das vom speicher eher unpraktisch ist
-
lookias schrieb:
aber dann muesste man in return 2 funktionsaufruse uebergeben(was ja nicht geht)
Wieso? Du rufst die Funktionen auf und machst dann erst dein return.
-
oh da hab ich bis jetzt nicht dran gedacht
das waere dann die uebrloesung danke
-
übrings ist sowas
if(b==true)doppeltgemoppelt. Ein
if(b)reicht.
-
Ist nicht doppelt gemoppelt, eher Geschmackssache. Ich lasse das "== true" aber auch ganz gerne weg.
-
doch ist doppelgemoppelt.
if((((b==true)==true)==true)==true)Sowas würde ich z.b. als fünffachgemoppelt bezeichnen und nicht als "geschmackssache"
-
Das ist nicht fünffach gemoppelt, sondern schlicht und einfach Blödsinn, aber auch wenn du es dir nicht vorstellen kannst: Manche Leute finden die explizite Schreibweise besser. Ich gehöre allerdings nicht dazu.
-
also ich kenn das zwar aber mir faellt das dann in der situation nicht ein
aber wenn ihr keinen andren fehler findet dann bin ich ganz zufrieden
-
Walli schrieb:
Das ist nicht fünffach gemoppelt, sondern schlicht und einfach Blödsinn
es ist blödsinn, auch wenns nicht falsch ist. Genauso wie if(b == true) --> ist nicht falsch aber blödsinn..
du meinst wahrscheinlich eher sowas: if(b != 0) bzw. if(b)..
was meinste denn was bei b == true rauskommt? richtig: true oder false. Wann kommt true? Wenn b true ist. Wann kommt false? Wenn b false ist. Was für einen Sinn hatte der vergleich? richtig: keinen.
-
life schrieb:
Genauso wie if(b == true) --> ist nicht falsch aber blödsinn..
Ist mir eigentlich egal ob es Blödsinn ist oder einfach nur ne explizite Schreibweise. Fakt ist: Es entstehen keine Nachteile dadurch und mancher findet es einfach schöner, warum auch immer. Ich habe das jedenfalls schon häufiger in fremden Codes gesehen und es stört meinen Lesefluss nicht. Wirklich blödsinnig wäre etwa if((b != 0) == true), da das "== true" nicht nur redundant ist, sondern zu allem Überfluss noch von der eigentlichen Condition ablenkt.
-
Walli schrieb:
[Fakt ist: Es entstehen keine Nachteile dadurch und mancher findet es einfach schöner, warum auch immer.
naja ein zusätzlicher vergleich... Mag ja sein dass der compiler das doppeltgemoppelte wegoptimiert, aber das ändert nix daran, dass es doppeltgemoppelt ist :>
-
life schrieb:
Walli schrieb:
[Fakt ist: Es entstehen keine Nachteile dadurch und mancher findet es einfach schöner, warum auch immer.
naja ein zusätzlicher vergleich... Mag ja sein dass der compiler das doppeltgemoppelte wegoptimiert, aber das ändert nix daran, dass es doppeltgemoppelt ist :>
Mag sein? Ich würde meinen Compiler sofort deinstallieren wenn er da ein zusätzliches cmp oder was auch immer einbaut. Wie gesagt: Ich bin auch so faul, dass ich das redundante "== true" nicht hinschreibe. Mich stört es aber nicht wenn es jemand tut.
-
Walli schrieb:
Mag sein? Ich würde meinen Compiler sofort deinstallieren wenn er da ein zusätzliches cmp oder was auch immer einbaut.
du meinst, du würdest den compiler deinstallieren, wenn er den zusätzlichen vergleich, den du explizit angibst, nicht wieder ausbaut, obwohl er offensichtlich überflüssig ist..
Wie gesagt: Ich bin auch so faul, dass ich das redundante "== true" nicht hinschreibe. Mich stört es aber nicht wenn es jemand tut.
das hat nichts mit faulheit zutun, sondern damit sinnvollen code zu produzieren im gegensatz zu zumindest teilweise sinnlosen code :>
Was würdeste sagen, wenn jemand ankommt und sagt: ich finde es unschön kommentare mit "//" oder "/*" einzuleiten. Ich leg dafür einfach immer eine temporäre string variable "kommentar" an:
{std::string kommentar("Hier könnte ihr Kommentar stehen!");}