Page 1 of 3 123 Last
  1. #1
    SDEC's Avatar
    Registered
    13/07/10
    Location
    VL-BR
    Posts
    147
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    0/0

    Break en/of return in een loop?

    Op school wordt ons aangeleerd dat een break/return in een lus (for/while/foreach) een slechte gewoonte is en dat we het niet mogen doen!

    Is dit nu echt zo? Ik vind breaken en returnen in een lus echter heel gemakkelijk en overzichtelijk + het spaart geheugen omdat je geen extra variabele moet aanmaken!

    Het argument op school is dat het "overzichtelijker" is voor de beginnende programmeur, we krijgen er zelfs minpunten voor op het examen, zelfs al is het perfect correcte syntax.

    Wat doen mensen in de praktijk nu? Iemand die dit argument ondersteund of het, zoals mij, ook totale onzin vind?


    Even om te verduidelijken:

    Zo moet het op school:
    Code:
    public void testFunc() {
        boolean stop = false;
    
        // for lus
        for(int i=0; i<MAX_IETS && stop == false; i++) {
            if(isIetsWaar()) {
                doeIets();
                stop = true;
            }
        }
    
        // while lus
        while(stop == false) {
            if(isIetsWaar()) {
                doeIets();
                stop = true;
            }
        }
    }
    Zo (vind ik) is het logischer:

    Code:
    public void testFunc() {
        // for lus
        for(int i=0; i<MAX_IETS; i++) {
            if(isIetsWaar()) {
                doeIets();
               break;
            }
        }
    
        // while lus
        while(true) {
            if(isIetsWaar()) {
                doeIets();
                break;
            }
        }
    }
    no votes  

  2. #2
    NeverwinterX's Avatar
    Registered
    27/08/04
    Location
    Leuven
    Posts
    930
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    11/38
    Mja het is bekend dat ze op veel scholen aanraden om dat zo te doen. Vermoedelijk vloeit dat voort uit dezelfde redering als het afwijzen van goto's.

    Maar ik ben het daar niet mee eens en de vergelijking met goto's is niet van toepassing. Bij een break of continue is het precies gedefinieerd naar waar je springt en er zijn geen verrassingen mogelijk. Bovendien verlies je het overzicht als de stopconditie wat ingewikkelder wordt: dan moet dat een lange boolean constructie worden. Bovendien is het gewoon overbodig en verboos.

    En scholen raden ook vaak aan om niet meerdere returns te hebben in een functie, vb:
    Code:
    public int foo(){
       int result;
       if(blabla)
          result = ....
    
       if(lalala){
          calculate something
          result = ...
       }
       else{
          more calculation
          result += ...
          more calculation
          result = ...
       }
    
       return result;
    }
    vs

    Code:
    public int foo(){
       int result;
       if(blabla)
          return x;
    
       if(lalala){
          calculate something
          return y;
       }
    
       more calculation
       result += ...
       more calculation
       return z;
    }
    Daar ben ik het al helemaal niet mee eens: meerdere returns is veel overzichtelijker en laat toe om alles meer op te delen in stukjes, wat het makkelijker te begrijpen maakt. Zodra je een return tegenkomt, hoe je over dat geval verder niet meer na te denken: anders moet je daar altijd nog rekening mee houden.
    Last edited by NeverwinterX; 02-12-2011 at 19:17.
    I am thee and thou art me and all of one is the other.
    TED talk: Richard Dawkins on militant atheism
    no votes  

  3. #3
    SDEC's Avatar
    Registered
    13/07/10
    Location
    VL-BR
    Posts
    147
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    0/0
    Quote Originally Posted by NeverwinterX View Post
    This quote is hidden because you are ignoring this member. Show
    ...
    Volkomen mee eens. Blijkbaar maken de docenten in het begin van het jaar de afspraak om het zo te doen, in het 3e semester is het dan ineens wel toegelaten om te breaken, returnen en te continueen waar je wilt.

    In de plaats van het ons in één keer deftig aan te leren...

    Code:
    if(blabla)
        return x;
    Mag ook niet, zelfs als het maar één statement is wordt er verplicht om haakjes te gebruiken. Slaat echt op niets... Akkoord het oogt mooier en de "beginnende programmeur" wordt er minder door verward maar is het dan zo fout om een andere (juiste) techniek ook te gebruiken?
    no votes  

  4. #4
    SideShow's Avatar
    Registered
    21/08/02
    Location
    Roeselare
    Posts
    4,474
    iTrader
    15 (100%)
    Mentioned
    0 Post(s)
    Reputation
    1/35
    in de meeste gevallen is het toch beter om je voorwaarden te centraliseren bovenaan in je lus, waar het hoort, maar inderdaad, af en toe (heel af en toe imo) is het leuker om gewoon in je code te breken...
    no votes  

  5. #5
    Fraggie's Avatar
    Registered
    17/07/02
    Posts
    9,537
    iTrader
    3 (100%)
    Mentioned
    0 Post(s)
    Reputation
    4/39
    Quote Originally Posted by SDEC View Post
    This quote is hidden because you are ignoring this member. Show
    In de plaats van het ons in één keer deftig aan te leren...
    Ik bevind mij de laatste tijd meer en meer in de embedded wereld en daar maakt het effectief een verschil.

    Allereerst moet je een onderscheid maken tussen:
    - for-loops die het gedrag van een while hebben (cf. vele breaks -> oplossing een while met: Lazy evaluation - Wikipedia, the free encyclopedia)
    - returnen in het midden van een methode zonder loops

    Enkel over het eerste kan ik mij uitspreken, de tweede doet er niet veel toe imo.

    Het zit namelijk zo dat wanneer je met embedded realtime applicatie te maken hebt je bijna altijd met pipelining te maken zult hebt. Hierbij kan de processor reeds bewerkingen 'prepareren' vooraleer ze worden uitgevoerd.
    Voor vele DSP toepassingen is het dus ongehoord dat je code hebt die:
    - de procossor toelaat om even voorop te lopen
    - en dan uit het niets de pipeline verbreekt
    => werk en tijd is verspilt! Want alle enkele bewerkingen hebben plots 0% betekenis en vele registers moeten eerst worden gecleared vooraleer de processor terug verder kan doen -> terug tijd verspilt.

    Wanneer je dan nog eens met multiple cores werkt wordt er nog meer tijd verspilt. De kans op glitches wordt ook groter.



    Wanneer je mooi en zuiver programmeert kan de compiler tips in ASM steken die helpen voor prediction voor de processor. Deze zal dan i.p.v. de instructies van een loop, die toch gebroken wordt, instructies gaan voorbereiden die NA de loop komen -> geen tijd verspilt.

    tl;dr: er is een reden waarom men zegt dat er geen goeie C programmers meer zijn.
    no votes  

  6. #6
    Cycloon's Avatar
    Registered
    18/01/04
    Location
    Melle
    Posts
    10,535
    iTrader
    56 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/102
    Ik heb het laatste jaar quasi constant met legacy code gewerkt waar for/while lussen vol zaten met vroegtijdige returns, continues, etc... Geloof mij vrij, vroeg of laat kom je een lus tegen waar de stopcondities zo onduidelijk worden dat refactoren en onderhoud een hell is. In kleine lusjes die je voor schoolopdrachten doet zal je nauwelijks inzien dat vroegtijdig een lus verlaten een slechte manier is van programmeren.

    Ik zou zeggen, trek geen stijlregels in twijfel wanneer je net begint te programmeren. Stijlregels kan je pas volledig appreciëren en begrijpen wanneer je meer ervaring hebt en voldoende situaties bent tegengekomen waar het onduidelijk wordt.
    “In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
    PSN: Cycloon - Final Fantasy XIV: A realm reborn character
    no votes  

  7. #7
    SDEC's Avatar
    Registered
    13/07/10
    Location
    VL-BR
    Posts
    147
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    0/0
    @Fraggie & Cycloon: Bedankt Dat is nu de goed geargumenteerde uitleg die ik hoopte te horen te krijgen.
    no votes  

  8. #8

    Registered
    18/02/06
    Location
    ghent
    Posts
    3,702
    iTrader
    12 (100%)
    Mentioned
    0 Post(s)
    Reputation
    1/11

    Post

    Quote Originally Posted by SDEC View Post
    This quote is hidden because you are ignoring this member. Show

    Mag ook niet, zelfs als het maar één statement is wordt er verplicht om haakjes te gebruiken. Slaat echt op niets...
    Tot je aan je code gaat sleutelen en een veel voorkomende fout programmeert. Oeps heb de haakjes vergeten.

    Als ik code bekijk dan wil ik direct zien wat het nu ervan is.
    Indien men een for gaat neerpennen dat in de loop der tijd gigantisch wordt dan kan ik niet direct zien wat er eigenlijk gaande is. Een goed gedefinieerde while lus geeft me direct de info die ik wil. Zoals hierboven vermeld is het inderdaad zo dat op 5 regels code het wel altijd duidelijk is maar stel dat de lus tientallen lijnen code bevat en daarin ergens de voorwaarde verwerkt zit om eruit te springen. Als een andere persoon naar die code zal kijken zal het zeer lastig zijn om te weten wat h'm doet.

    Code:
    for(....){
        ....
        (if negatief gevonden)
        return
    }
    vs

    Code:
    while( geen negatief gevonden && niet door m'n set....){
        ....
        (if negatief)
        negatief gevonden = true
    }
    Als ik bovenstaande while lees dan weet ik direct dat men iets negatiefs gaat zoeken waar dit in de while structuur absoluut niet duidelijk is.
    no votes  

  9. #9
    forloRn_'s Avatar
    Registered
    23/11/03
    Location
    Landeurp
    Posts
    1,791
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    10/17
    Als je resoluut voor manier A dan wel manier B kiest, ga je je op den duur weer in bochten moeten wringen. Wees een beetje pragmatisch en schrijf het gewoon op de meest leesbare manier. Er zijn andere dingen om van wakker te liggen, dunkt me.
    no votes  

  10. #10
    Ice's Avatar
    Registered
    31/07/02
    Location
    Kontich
    Posts
    602
    iTrader
    16 (100%)
    Mentioned
    0 Post(s)
    Reputation
    0/0
    Quote Originally Posted by SDEC View Post
    This quote is hidden because you are ignoring this member. Show
    Code:
    if(blabla)
        return x;
    Mag ook niet, zelfs als het maar één statement is wordt er verplicht om haakjes te gebruiken. Slaat echt op niets... Akkoord het oogt mooier en de "beginnende programmeur" wordt er minder door verward maar is het dan zo fout om een andere (juiste) techniek ook te gebruiken?
    Protip: schrijf ALTIJD haakjes.
    Waarom? Omdat er gegarandeerd iemand na u die code gaat aanpassen.
    Als er dan ineens het volgende komt te staan is uw code omzeep.
    Code:
     if (blabla) 
        calMyMethod(x);
        return x;
    Zo'n fout is sneller gemaakt dan je denkt en niet altijd even eenvoudig terug te vinden. We leven nu eenmaal niet in een ideale wereld waar alles perfect en automatisch wordt getest.
    When you're slapped, you'll take it and like it - Sam Spade
    Make way for the bad guy! - Tony Montana
    When a girl has a heart of stone, there's only one way to melt it. Just add Ice.
    no votes  

  11. #11
    metalleke's Avatar
    Registered
    23/10/03
    Location
    Oostende
    Posts
    2,782
    iTrader
    3 (100%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by NeverwinterX View Post
    This quote is hidden because you are ignoring this member. Show
    Mja het is bekend dat ze op veel scholen aanraden om dat zo te doen. Vermoedelijk vloeit dat voort uit dezelfde redering als het afwijzen van goto's.
    De regel om geen gebruik te maken van early returns komt gewoon uit de talen waar je nog zelf geheugenbeheer moet doen.

    Goto's geven eerder aanleiding tot spaghetticode, terwijl early returns aanleiding geven tot memoryleaks.

    Quote Originally Posted by Cycloon View Post
    This quote is hidden because you are ignoring this member. Show
    Ik heb het laatste jaar quasi constant met legacy code gewerkt waar for/while lussen vol zaten met vroegtijdige returns, continues, etc... Geloof mij vrij, vroeg of laat kom je een lus tegen waar de stopcondities zo onduidelijk worden dat refactoren en onderhoud een hell is. In kleine lusjes die je voor schoolopdrachten doet zal je nauwelijks inzien dat vroegtijdig een lus verlaten een slechte manier is van programmeren.

    Ik zou zeggen, trek geen stijlregels in twijfel wanneer je net begint te programmeren. Stijlregels kan je pas volledig appreciëren en begrijpen wanneer je meer ervaring hebt en voldoende situaties bent tegengekomen waar het onduidelijk wordt.
    Slechte code refactoren is gewoon altijd een hell.

    You should quit worrying about micro-optimizations and start worrying about indenting code in a way that people can read it.
    Notch: But let’s get one thing clear: people who think “free to play” is a great future are mostly game developers, not game players.
    no votes  

  12. #12
    NeverwinterX's Avatar
    Registered
    27/08/04
    Location
    Leuven
    Posts
    930
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    11/38
    Quote Originally Posted by Ice View Post
    This quote is hidden because you are ignoring this member. Show
    Protip: schrijf ALTIJD haakjes.
    Waarom? Omdat er gegarandeerd iemand na u die code gaat aanpassen.
    Als er dan ineens het volgende komt te staan is uw code omzeep.
    Code:
     if (blabla) 
        calMyMethod(x);
        return x;
    Zo'n fout is sneller gemaakt dan je denkt en niet altijd even eenvoudig terug te vinden. We leven nu eenmaal niet in een ideale wereld waar alles perfect en automatisch wordt getest.
    Imo verdient die persoon dan gewoon slaag omdat die duidelijk geen IDE gebruikt. Ik zet die haakjes eerder omdat het dan later makkelijker is om een statement toe te voegen binnen de if.

    Quote Originally Posted by Fraggie View Post
    This quote is hidden because you are ignoring this member. Show
    Ik bevind mij de laatste tijd meer en meer in de embedded wereld en daar maakt het effectief een verschil.

    Allereerst moet je een onderscheid maken tussen:
    - for-loops die het gedrag van een while hebben (cf. vele breaks -> oplossing een while met: Lazy evaluation - Wikipedia, the free encyclopedia)
    - returnen in het midden van een methode zonder loops

    Enkel over het eerste kan ik mij uitspreken, de tweede doet er niet veel toe imo.

    Het zit namelijk zo dat wanneer je met embedded realtime applicatie te maken hebt je bijna altijd met pipelining te maken zult hebt. Hierbij kan de processor reeds bewerkingen 'prepareren' vooraleer ze worden uitgevoerd.
    Voor vele DSP toepassingen is het dus ongehoord dat je code hebt die:
    - de procossor toelaat om even voorop te lopen
    - en dan uit het niets de pipeline verbreekt
    => werk en tijd is verspilt! Want alle enkele bewerkingen hebben plots 0% betekenis en vele registers moeten eerst worden gecleared vooraleer de processor terug verder kan doen -> terug tijd verspilt.

    Wanneer je dan nog eens met multiple cores werkt wordt er nog meer tijd verspilt. De kans op glitches wordt ook groter.



    Wanneer je mooi en zuiver programmeert kan de compiler tips in ASM steken die helpen voor prediction voor de processor. Deze zal dan i.p.v. de instructies van een loop, die toch gebroken wordt, instructies gaan voorbereiden die NA de loop komen -> geen tijd verspilt.

    tl;dr: er is een reden waarom men zegt dat er geen goeie C programmers meer zijn.
    Embedded programmeren is inderdaad wel een geval apart. Maar of je nu een if/else binnen je for loop hebt of break/continue: in beide gevallen zal je pipeline dan dingen voorberekenen die nutteloos blijken. Dan kun je wel weer verder gaan optimaliseren om dat te vermijden, maar dat gaat voor beide gevallen op. Je kan zelfs je loops gaan unrollen en heel die shit. Als dat tenminste echt nodig is en echt iets uithaalt, want premature optimisation... En dan nog worden de processoren steeds complexer waardoor het bijzonder moeilijk is om je code correct te optimaliseren voor de pipeline en multilevel caching en die hele resem nieuwe technieken van tegenwoordig, die dan ook nog eens verschillen per processor. Sommige van die optimalisaties van vroeger die nog steeds worden doorverteld, kunnen tegenwoordig geen effect meer of zelfs een omgekeerd effect hebben.
    Last edited by NeverwinterX; 02-12-2011 at 19:30.
    I am thee and thou art me and all of one is the other.
    TED talk: Richard Dawkins on militant atheism
    no votes  

  13. #13
    Cycloon's Avatar
    Registered
    18/01/04
    Location
    Melle
    Posts
    10,535
    iTrader
    56 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/102
    Quote Originally Posted by metalleke View Post
    This quote is hidden because you are ignoring this member. Show
    Slechte code refactoren is gewoon altijd een hell.
    Idd, daarom dat we moeten voorkomen dat er nog slechte code wordt geschreven . Stijlregels zijn een begin.
    “In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
    PSN: Cycloon - Final Fantasy XIV: A realm reborn character
    no votes  

  14. #14
    Parnakra's Avatar
    Registered
    15/04/04
    Location
    Izegem
    Posts
    6,095
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Stijlregels mogen geen voorrang hebben op pragmatiek.

    Het single entrance/single exit gedachtengoed heeft z'n roots in talen die vandaag de dag doorgaans niet meer relevant zijn. Dus er aan vastklingen gewoon 'omdat het zo moet' is belachelijk. Denk zelf even na of een break of return in een lus van 5 à 10 lijntjes nog leesbaar is (veel langer moeten ze trouwens niet worden, of er klopt iets niet), of als je toch met een tijdelijke variabele werkt.
    no votes  

  15. #15
    dJeez's Avatar
    Registered
    17/07/02
    Location
    Sol System
    Posts
    10,064
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/78
    Quote Originally Posted by Cycloon View Post
    This quote is hidden because you are ignoring this member. Show
    Ik heb het laatste jaar quasi constant met legacy code gewerkt waar for/while lussen vol zaten met vroegtijdige returns, continues, etc... Geloof mij vrij, vroeg of laat kom je een lus tegen waar de stopcondities zo onduidelijk worden dat refactoren en onderhoud een hell is.
    Daar hebben we dan ook unit tests voor he, om te testen of niks breekt bij het refactoren .
    PSN: dJeezBE - Delicious bookmarks
    Disclaimer: I am currently suffering from severe CSD (Compulsive Sarcasm Disorder). - L'onion fait la farce - Facile largire de alieno
    Pastafarian by choice
    no votes  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in