Thread: Break en/of return in een loop?
-
01-12-2011, 20:30 #1
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:
Zo (vind ik) is het logischer: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; } } }
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
-
-
01-12-2011, 20:40 #2Approved 9-lifer
- 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:
vsCode:public int foo(){ int result; if(blabla) result = .... if(lalala){ calculate something result = ... } else{ more calculation result += ... more calculation result = ... } return result; }
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.Code:public int foo(){ int result; if(blabla) return x; if(lalala){ calculate something return y; } more calculation result += ... more calculation return z; }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 atheismno votes
-
01-12-2011, 21:09 #3
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...
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?Code:if(blabla) return x;no votes
-
01-12-2011, 21:40 #4Approved 9liver
- 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
-
01-12-2011, 21:53 #5
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
-
01-12-2011, 22:35 #6Approved 9liver
- 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 characterno votes
-
02-12-2011, 00:22 #7
@Fraggie & Cycloon: Bedankt
Dat is nu de goed geargumenteerde uitleg die ik hoopte te horen te krijgen.
no votes
-
02-12-2011, 10:50 #8Member
- Registered
- 18/02/06
- Location
- ghent
- Posts
- 3,702
- iTrader
- 12 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 1/11
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.
vsCode:for(....){ .... (if negatief gevonden) return }
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.Code:while( geen negatief gevonden && niet door m'n set....){ .... (if negatief) negatief gevonden = true }no votes
-
02-12-2011, 13:14 #9Member
- 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
-
02-12-2011, 15:35 #10Member
- Registered
- 31/07/02
- Location
- Kontich
- Posts
- 602
- iTrader
- 16 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 0/0
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.
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.Code:if (blabla) calMyMethod(x); return x;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
-
02-12-2011, 18:10 #11Approved 9liver
- Registered
- 23/10/03
- Location
- Oostende
- Posts
- 2,782
- iTrader
- 3 (100%)
- Mentioned
- 0 Post(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.
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
-
02-12-2011, 19:25 #12Approved 9-lifer
- Registered
- 27/08/04
- Location
- Leuven
- Posts
- 930
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 11/38
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.
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 atheismno votes
-
02-12-2011, 19:48 #13Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
“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 characterno votes
-
02-12-2011, 21:03 #14
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
-
02-12-2011, 22:24 #15Member
- Registered
- 17/07/02
- Location
- Sol System
- Posts
- 10,064
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/78
PSN: dJeezBE - Delicious bookmarks
Disclaimer: I am currently suffering from severe CSD (Compulsive Sarcasm Disorder). - L'onion fait la farce - Facile largire de alienoPastafarian by choiceno votes

.
