Page 3 of 5 First 12345 Last
  1. #31
    Parnakra's Avatar
    Registered
    15/04/04
    Location
    Izegem
    Posts
    6,095
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by MilM View Post
    This quote is hidden because you are ignoring this member. Show
    Ik geef u wel gelijk dat voor zeer grote blokken (waar je dan zelfs in een goeie IDE mss snel over 'return true' gaat lezen) het beter kan zijn om te werken met een conditie binnen te haakskes ipv een return of break statement.
    Quote Originally Posted by Parnakra View Post
    This quote is hidden because you are ignoring this member. Show
    Laat dat de regel zijn, en een for met slechts 3 lijntjes de uitzondering.
    Ik denk dat we op dezelfde pagina zitten.

    /edit: holy crap, wat een anglicisme. =/
    no votes  

  2. #32
    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 MilM View Post
    This quote is hidden because you are ignoring this member. Show
    Ik vind het dan ook overdreven om iemand hierop te pakken in dit voorbeeld.
    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 character
    no votes  

  3. #33

    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  

  4. #34
    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 MilM View Post
    This quote is hidden because you are ignoring this member. Show
    Btw, het was niet "mijn" code hé Het was iemand anders die dat gepost had.
    Ja natuurlijk, had er ff niet bij stilgestaan
    “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  

  5. #35
    Kemblin's Avatar
    Registered
    14/05/03
    Location
    Schoten
    Posts
    812
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Reputation
    1/7
    Quote Originally Posted by Cycloon View Post
    This quote is hidden because you are ignoring this member. Show
    Jij springt zomaar ergens halfweg uit je for lus. Een for lus dient er voor om x keer dezelfde code te herhalen en in beide code wordt de for lus vroegtijdig afgebroken als een item reeds bestaat. De TS doet zich wel nog de moeite om alle voorwaarden duidelijk in de forlus te houden, jij gebruikt gewoon een lompe return in je for lus. Qua leesbaarheid is dat echt 0.

    In dit geval zou de code van de TS goed geweest zijn had hij zich de moeite genomen om een while lus te schrijven.

    (het gaat hier dus vooral over hoe leesbaar en duidelijk programmeert, ik heb me niet uitgesproken over de efficiëntie van de gegeven code)
    Ok, een klein voorbeeldje

    volgens u richtlijnen (alles in de lus houden):
    Code:
    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;
    Gij vindt dat dus duidelijker dan

    Code:
    for(int i=0; i < collec.size(); i++){
    	if(blabli)
    		return false;
    	else if(blabla)
    		return false;
    	else if(blablo)
    		return true;
    }
    kweetnie ze
    no votes  

  6. #36
    Gurdt's Avatar
    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? :O
    no votes  

  7. #37
    Gurdt's Avatar
    Registered
    21/08/08
    Location
    Hasselt
    Posts
    2,653
    iTrader
    8 (100%)
    Mentioned
    0 Post(s)
    Reputation
    5/46
    Quote Originally Posted by Kemblin View Post
    This quote is hidden because you are ignoring this member. Show
    Ok, een klein voorbeeldje

    volgens u richtlijnen (alles in de lus houden):
    Code:
    slechte code
    Gij vindt dat dus duidelijker dan

    Code:
    goede code
    }
    kweetnie ze
    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 it
    no votes  

  8. #38

    Registered
    03/08/02
    Location
    Gavere
    Posts
    37,519
    iTrader
    23 (100%)
    Mentioned
    57 Post(s)
    Reputation
    0/1281
    Quote Originally Posted by Gurdt View Post
    This quote is hidden because you are ignoring this member. Show
    return'en in een while of een forlus moet kunnen,
    anders kan je evengoed het keywoord 'break' uit uw syntax schrappen

    ...

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

  9. #39
    forloRn_'s Avatar
    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);
    }
    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
    }
    Twee exceptions worden gewoon genegeerd, terwijl hij elders in het document dit zegt:
    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.
    Hier heb ik ook mijn bedenkingen bij:
    WRONG
    Code:
    for (Enumeration enum = getEnum(); enum.hasMoreElements();) {
        Object o = enum.nextElement();
        doSomeProc(o);
    }
    RIGHT
    Code:
    Enumeration enum = getEnum();
    while (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.

    Do not chain method calls. Exceptionally, a chain of 2 method calls can be used.

    Take the following line of code:
    Code:
    ret = object.method1().method2().method3();
    If the return value from one of the methods is null you would get a NullPointerException. But which one is it?

    It's better to use:
    Code:
    ret1 = object.method1();
    ret2 = ret1.mehthod2();
    ret3 = ret2.method3();
    Een hoop nutteloze lokale variabelen introduceren dus, wat weer onoverzichtelijk is.
    no votes  

  10. #40

    Registered
    03/08/02
    Location
    Gavere
    Posts
    37,519
    iTrader
    23 (100%)
    Mentioned
    57 Post(s)
    Reputation
    0/1281
    Quote Originally Posted by forloRn_ View Post
    This quote is hidden because you are ignoring this member. Show
    Twee exceptions worden gewoon genegeerd, terwijl hij elders in het document dit zegt:
    Empty catch blocks <-> catch blocks met tenminste een LOG statement in. Toch?

    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.
    Feel free om feedback te geven. Kan nog interessante discussie geven, maar ga er niet van uit dat de guidelines ondoordacht zijn opgesteld.

    Een hoop nutteloze lokale variabelen introduceren dus, wat weer onoverzichtelijk is.
    Point stands: hoe ga je weten waar de NPE zit? Die regel dient specifiek daarvoor.
    no votes  

  11. #41
    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 eniac View Post
    This quote is hidden because you are ignoring this member. Show
    Point stands: hoe ga je weten waar de NPE zit? Die regel dient specifiek daarvoor.
    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;
    };
    Code:
    double getPayAmount() {
    	if (_isDead) return deadAmount();
    	if (_isSeparated) return separatedAmount();
    	if (_isRetired) return retiredAmount();
    	return normalPayAmount();
    };
    Dus ... waarom zijn multiple returns zo slecht?
    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. #42
    forloRn_'s Avatar
    Registered
    23/11/03
    Location
    Landeurp
    Posts
    1,791
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    10/17
    Quote Originally Posted by eniac View Post
    This quote is hidden because you are ignoring this member. Show
    Empty catch blocks <-> catch blocks met tenminste een LOG statement in. Toch?
    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.

    Quote Originally Posted by eniac View Post
    This quote is hidden because you are ignoring this member. Show
    Point stands: hoe ga je weten waar de NPE zit? Die regel dient specifiek daarvoor.
    Debuggen?
    no votes  

  13. #43

    Registered
    03/08/02
    Location
    Gavere
    Posts
    37,519
    iTrader
    23 (100%)
    Mentioned
    57 Post(s)
    Reputation
    0/1281
    Quote Originally Posted by Ice View Post
    This quote is hidden because you are ignoring this member. Show
    Als je NPE hebt ga je wrsch toch ff debuggen, dus whats the problem?
    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.


    dan nog ff over multiple returns:
    Je maakt je eerste blok wel nodeloos onoverzichtelijk. Beetje oneerlijk hoor
    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;
    }

    Quote Originally Posted by forloRn_ View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    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  

  14. #44
    forloRn_'s Avatar
    Registered
    23/11/03
    Location
    Landeurp
    Posts
    1,791
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    10/17
    Quote Originally Posted by eniac View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    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  

  15. #45

    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  

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