ist break wirklich schlechter programmierstil?



  • 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!");}
    


  • life schrieb:

    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..

    Ne, ich würde den Compiler deinstallieren wenn er mir einen zusätzlichen Vergleich den wen anders angibt nicht wieder ausbaut obwohl er offensichtlich überflüssig ist. Ich mache so etwas nicht, schon vergessen? Dabei habe ich es in bestimmt 2 Posts erwähnt...

    life schrieb:

    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 :>

    Ja, es gibt auch Leute die so etwas schreiben: for(int i = 0; i < 100; i++).
    Finde ich auch schrecklich, obwohl jeder Compiler das optimiert. Glücklicherweise gibt es aber wichtigere Sachen um die ich mich kümmern muss, sonst würde ich bis spät in die Nacht solche sinnlosen Sachen in fremden Codes ausbessern.

    life schrieb:

    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!");}
    

    Das ist keine Geschmackssache, sondern Dummheit. Solchen Code würde ich nicht benutzen, weil der Autor offensichtlich schon Probleme mit den grundlegensten Sachen hat. Das hat aber absolut überhaupt nichts mit dem Thema zu tun! Ich kenne hervorragende Programmierer die halt if(b == true) lieber schreiben als if(b), da letzteres ihnen nicht explizit genug ist. Es ist mir aber egal, denn ich kann da wunderbar drüber hinweg lesen und es tut auch dem Code nicht weh. Die Frage ist also in die Kategorie Stil einzuordnen, genauso wie die Frage ob man der geschweiften Klammer eine Extra-Zeile spendieren soll.

    Falls es noch nicht deutlich genug rübergekommen ist: Ich finde die Diskussion ermüdend...



  • Walli schrieb:

    Ja, es gibt auch Leute die so etwas schreiben: for(int i = 0; i < 100; i++).
    Finde ich auch schrecklich, obwohl jeder Compiler das optimiert.

    was ist daran schrecklich? das 'int' da drin?


Anmelden zum Antworten