-
11-03-2009, 15:59 #31no votes
-
-
11-03-2009, 17:29 #32Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
Mijn punt was net dat jij jouw code als beter ging voorstellen omdat ze uit minder code bestond terwijl jouw code dus op zich niet echt beter was. Het is duidelijk dat de TS een beginner is en hij wel probeert te programmeren volgens de regels van de kunst. Ook al gaat het hier om kleine stukjes code, dat verandert niks aan de kwestie. Beginners gaan altijd met korte code werken dus dat zou praktisch betekenen dat ze nooit in hun leven nog de overstap gaan maken naar duidelijke code.
Laat het gewoon duidelijk zijn dat bij elke methode max 1 return hoort.
Voor de rest heeft parnakra al genoeg gezegd
“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
-
11-03-2009, 17:58 #33Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
Ik had het vooral op volgende zin eigenlijk: "In dit geval zou de code van de TS goed geweest zijn had hij zich de moeite genomen om een while lus te schrijven"
Nu kom, ik denk dat er veel woorden geschreven zijn voor uiteindelijk een klein puntje
Btw, het was niet "mijn" code hé
Het was iemand anders die dat gepost had.
no votes
-
11-03-2009, 18:49 #34Approved 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
-
12-03-2009, 01:04 #35Member
- Registered
- 14/05/03
- Location
- Schoten
- Posts
- 812
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 1/7
Ok, een klein voorbeeldje
volgens u richtlijnen (alles in de lus houden):
Gij vindt dat dus duidelijker danCode:int i=0; boolean temp1 = true; boolean temp2 = true; boolean temp3 = false; while( i < collec.size() && (temp1 && temp2 && !temp3) ){ if(blabli) temp1 = false; else if(blabla) temp2 = false; else if(blablo) temp3 = true; i++; } return !temp1 || !temp2 || temp3;
kweetnie zeCode:for(int i=0; i < collec.size(); i++){ if(blabli) return false; else if(blabla) return false; else if(blablo) return true; }
no votes
-
12-03-2009, 01:11 #36Approved 9-lifer
- Registered
- 21/08/08
- Location
- Hasselt
- Posts
- 2,653
- iTrader
- 8 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 5/46
ge kunt ook syntax highlighting gebruiken, dan zie je meteen waar een return-statement staat (in mijn programmeeromgeving is dat namelijk knalblauw)
die syntax highlighting heeft een nut, namelijk de leesbaarheid, das nie voor de pipo-clowns onder ons erin gezet
return'en in een while of een forlus moet kunnen,
anders kan je evengoed het keywoord 'break' uit uw syntax schrappen
---
die return is precies hetzelfde als een boolean gebruiken en die als testconditie gaat meegebruiken
met als enige verschil: die testconditie gaat iedere keer geevalueerd moeten worden, dus minder efficient
als gij dan in een forlus zit die door gegevens loopt, gaat ge de complexiteit verdubbelen
--
maw: volgens MIJ is returnen in een while-lus of een forlus best mogelijk
en als er zeikerds zijn die dat nie leesbaar vinden, lees dan de commentaar die erboven staat, oh wacht, die schrijven die oude mensen die al jaren ervaring hebben niet? :Ono votes
-
12-03-2009, 01:14 #37Approved 9-lifer
- Registered
- 21/08/08
- Location
- Hasselt
- Posts
- 2,653
- iTrader
- 8 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 5/46
ik geef u heel hard gelijk
nie alleen is die bovenste lelijk en onleesbaar, da is ook nog eens efficient
in beide lussen gaat ge in het slechtste geval 3 testconditie's hebben, ma das gelijk bij beiden dus moet ge nie beschouwen
MAAR die bovenste gaat ALTIJD nog eens 3 testcondities overlopen (4 eigelijk maar 3 ervan zijn nutteloos, lazy-evaluation niet meegerekend)
de onderste NIET
conclusie: onderste code is 'beter'
face itno votes
-
12-03-2009, 08:41 #38Member
- Registered
- 03/08/02
- Location
- Gavere
- Posts
- 37,519
- iTrader
- 23 (100%)
- Mentioned
- 57 Post(s)
- Reputation
- 0/1281
Bekijk dit eens:
https://jjguidelines.dev.java.net/bo...4.html#JAC_016
Wees gerust, deze zijn niet opgesteld door amateurs (tenzij je Stephan Janssen een amateur wil noemen natuurlijk, maar dan ben je compleet op je kop gevallen) en worden erg vaak gebruikt. Mijn ant/maven builds falen zelfs indien er gezondigd wordt tegen de regels.
Het gebruik van break wordt trouwens niet aangemoedigd, en wel voor een reden. Behalve natuurlijk in switch statements.no votes
-
12-03-2009, 10:33 #39Member
- Registered
- 23/11/03
- Location
- Landeurp
- Posts
- 1,791
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 10/17
Ik zie daar nuttige dingen in staan, ik zie daar ook regelrechte stinkers in staan:
RIGHT
Code:try { name = rs.getString(1); } catch (SQLException e) { logger.log(Level.WARNING, "SQL Problem", e); }Twee exceptions worden gewoon genegeerd, terwijl hij elders in het document dit zegt:RIGHT
Code:try { file = new FileInputStream("myfile"); } catch (IOException e) { logger.log(Level.WARNING, "File myfile not found"); } finally { // If the file is open, close it here }
Hier heb ik ook mijn bedenkingen bij:catch blocks should not be empty. Programmers frequently forget to process negative outcomes of a program and tend to focus more on the positive outcomes.
WRONG
Code:for (Enumeration enum = getEnum(); enum.hasMoreElements();) { Object o = enum.nextElement(); doSomeProc(o); }In het eerste geval staat je Enumeration altijd vlak bij de code die er gebruik van maakt (overzichtelijk), en je verkleint er de scope nog mee ook.RIGHT
Code:Enumeration enum = getEnum(); while (enum.hasMoreElements()) { Object o = enum.nextElement(); doSomeProc(o); }
Een hoop nutteloze lokale variabelen introduceren dus, wat weer onoverzichtelijk is.Do not chain method calls. Exceptionally, a chain of 2 method calls can be used.
Take the following line of code:
If the return value from one of the methods is null you would get a NullPointerException. But which one is it?Code:ret = object.method1().method2().method3();
It's better to use:
Code:ret1 = object.method1(); ret2 = ret1.mehthod2(); ret3 = ret2.method3();
no votes
-
12-03-2009, 10:47 #40Member
- Registered
- 03/08/02
- Location
- Gavere
- Posts
- 37,519
- iTrader
- 23 (100%)
- Mentioned
- 57 Post(s)
- Reputation
- 0/1281
Empty catch blocks <-> catch blocks met tenminste een LOG statement in. Toch?
Feel free om feedback te geven. Kan nog interessante discussie geven, maar ga er niet van uit dat de guidelines ondoordacht zijn opgesteld.In het eerste geval staat je Enumeration altijd vlak bij de code die er gebruik van maakt (overzichtelijk), en je verkleint er de scope nog mee ook.
Point stands: hoe ga je weten waar de NPE zit? Die regel dient specifiek daarvoor.Een hoop nutteloze lokale variabelen introduceren dus, wat weer onoverzichtelijk is.no votes
-
12-03-2009, 11:24 #41Member
- Registered
- 31/07/02
- Location
- Kontich
- Posts
- 602
- iTrader
- 16 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 0/0
Omdat je een error krijgt in de zin van: "UndefinedObject does not understand method3" ... ow juist, tis java ...
Als je NPE hebt ga je wrsch toch ff debuggen, dus whats the problem?
dan nog ff over multiple returns:
Code:double getPayAmount() { double result; if (_isDead) result = deadAmount(); else { if (_isSeparated) result = separatedAmount(); else { if (_isRetired) result = retiredAmount(); else result = normalPayAmount(); }; } return result; };Dus ... waarom zijn multiple returns zo slecht?Code:double getPayAmount() { if (_isDead) return deadAmount(); if (_isSeparated) return separatedAmount(); if (_isRetired) return retiredAmount(); return normalPayAmount(); };
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
-
12-03-2009, 11:30 #42Member
- Registered
- 23/11/03
- Location
- Landeurp
- Posts
- 1,791
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 10/17
En wat is de gebruiker met dat log statement? Dat is er volgens mij nog altijd voor programmeurs. Voor de gebruiker lijkt het programma te werken terwijl het serieus aan het mislopen is.
Debuggen?no votes
-
12-03-2009, 11:46 #43Member
- Registered
- 03/08/02
- Location
- Gavere
- Posts
- 37,519
- iTrader
- 23 (100%)
- Mentioned
- 57 Post(s)
- Reputation
- 0/1281
Debuggen is fameus krachtig, maar bvb een lokale server in debug mode opstarten duurt net wat langer dan gewoon in een stacktrace te zien op welke regel de NPE optrad en naar die code te springen.
Deze regel kan dus tijd besparen en zal nooit tijd kosten.
Je maakt je eerste blok wel nodeloos onoverzichtelijk. Beetje oneerlijk hoordan nog ff over multiple returns:
Je kan dat eerste blok bijna net zo kort schrijven als je tweede:
Code:double getPayAmount() { double result; if (_isDead) result = deadAmount(); else if (_isSeparated) result = separatedAmount(); else if (_isRetired) result = retiredAmount(); else result = normalPayAmount(); return result; }
Of je aan de gebruiker normale input wil tonen is zeer specifiek aan je huidige business en kan je dus zelf wel beslissen.
LOG.fatal statements kunnen bvb het sturen van mails triggeren. Verantwoordelijke persoon ontvangt mail met SQLException stacktrace en bekijkt wat er gaande is. Klein voorbeeldje maar, maar laat het duidelijk wezen dat er een verschil is tussen // in een methode en toch iets dat iets doet.no votes
-
12-03-2009, 11:55 #44Member
- Registered
- 23/11/03
- Location
- Landeurp
- Posts
- 1,791
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 10/17
Zoals ik al zei, voor de gebruiker maakt het echt niets uit of daar nu niets staat in dat catch-block, of een log statement. Het resultaat is hetzelfde: het programma werkt niet, maar gedraagt zich alsof het wel werkt. Het minste wat je kan doen is die exception naar boven laten propageren en een foutboodschap tonen.
no votes
-
12-03-2009, 12:05 #45Member
- Registered
- 03/08/02
- Location
- Gavere
- Posts
- 37,519
- iTrader
- 23 (100%)
- Mentioned
- 57 Post(s)
- Reputation
- 0/1281
Maar zoals ik al zei, is het zeer situatie-afhankelijk of je überhaupt een foutmelding aan de gebruiker wil tonen. Dat beslis je zelf.
no votes

