Archief - [JAVA] Static reference in a non-static method

Kemblin · 10 mrt 2009

Ice zei:
Je bedoelt zoals in LinkedHashSet (Java 2 Platform SE v1.4.2) ?

wat als hij een ArrayList gewoon handiger vond om mee te werken, hoe dan ook het is niet mijn keuze dus bij mij moet ge niet zijn...

jeez ik had al beter niks gepost

Ice · 10 mrt 2009

Kemblin zei:
wat als hij een ArrayList gewoon handiger vond om mee te werken?

jeez ik had al beter niks gepost

Njah, kvind gewoon dat mensen beter eens hun basic collections leren ipv altijd opnieuw het wiel uit te vinden.

Bubbling Zombie · 10 mrt 2009

Kemblin zei:
wat als hij een ArrayList gewoon handiger vond om mee te werken, hoe dan ook het is niet mijn keuze dus bij mij moet ge niet zijn...

jeez ik had al beter niks gepost

Dan gebruikt hij een verkeerde collectie voor zijn doel?

Cycloon · 10 mrt 2009

Kemblin zei:
waarom?

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)

eniac · 10 mrt 2009

Ice zei:
Njah, kvind gewoon dat mensen beter eens hun basic collections leren ipv altijd opnieuw het wiel uit te vinden.

Nu kunnen er wel bepaalde redenen zijn om een Linked-variant van een collection te vermijden, zoals performance. Maar het lijkt me straf dat dat hier al een issue zou zijn, dus ik geef je wel hard gelijk

Met een linkedhashset wordt het blok code dan gewoon:

Code:

return eigenaars.add(eigenaar);

Indien de eigenaar al bestond returned dit gewoon false, anders add hij en returned het true.

Natuurlijk wel voor een deftige equals() en hashCode() override zorgen in Eigenaar.

MilM · 11 mrt 2009

Cycloon zei:
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)

Hier ga ik niet mee akkoord.
Je hebt een teller nodig, je moet deze per loop incrementeren en je moet in het slechtste geval de volledige collectie doorlopen.

Waarom zou je dan geen for lus mogen gebruiken?

Of je dat doet met een boolean variabele of door direct uit de lus te springen is een voorkeur.
Ik vind die code niet slecht (los van de collectie keuze).

De redenering dat je verplicht een while lus moet gebruiken wanneer er vroegtijdig uit de lus kan gesprongen worden vind ik belachelijk.

Parnakra · 11 mrt 2009

Zoals Cycloon zei, dat is noodzakelijk als je leesbare code wil maken.

Als ik code lees en ik zie een for-lus staan, dan bekijk ik de voorwaarden en hoeveel keer de lus doorlopen wordt. Hetgeen in de lus uitgevoerd wordt, staat los van die voorwaarden.

Als er dan in die for-lus opeens abrupt gestopt wordt, kan mijn beeld van hoe het programma/stuk code werkt niet kloppen.

MilM · 11 mrt 2009

En sinds wanneer kun je die extra voorwaarden (een hulpvariabele) niet in uw for lus zetten?
Dat is toch hetzelfde als bij een while lus ...

We zijn hier bezig over een loop die met behulp van een for lus in drie regels geschreven kan worden.
Als dat al niet meer leesbaar is, waar zijn we dan mee bezig?

We hebben het dus bijv. over

Code:

for(int i = 0; i < collec.size(); i++)
	if(collec.equals("test"))
		return true;
return false;

vs

Code:

int i=0;
boolean temp = false;
while( i < collec.size() && !temp){
	if(collec.equals("test"))
		temp = true;
        i++;
}
return temp;

Het eerste vind ik persoonlijk zelfs veel duidelijker, aangezien je bij het tweede stuk nog moet nadenken over die hulpvariabele ...
Nu, dat zijn persoonlijke voorkeuren.
Om daar dan een preek over te gaan geven

Parnakra · 11 mrt 2009

MilM zei:
En sinds wanneer kun je die extra voorwaarden (een hulpvariabele) niet in uw for lus zetten?
Dat is toch hetzelfde als bij een while lus ...

We zijn hier bezig over een loop die met behulp van een for lus in drie regels geschreven kan worden.
Als dat al niet meer leesbaar is, waar zijn we dan mee bezig?

We hebben het dus bijv. over

Code:

for(int i = 0; i < collec.size(); i++) if(collec.equals("test")) return true; return false;

vs

Code:

int i=0; boolean temp = false; while( i < collec.size() && !temp){ if(collec.equals("test")) temp = false; return temp;

Het eerste vind ik persoonlijk zelfs duidelijk, aangezien je bij het tweede stuk nog moet nadenken over die hulpvariabele ...
Nu, dat zijn persoonlijke voorkeuren.
Om daar dan een preek over te gaan geven

Niet alle for- of while-lussen bestaan uit 3 regeltjes code.

En dat zouden geen persoonlijke voorkeuren moeten zijn, je kan alles wat je met een forlus kan doen ook met een whilelus doen, en vice versa. Het grote verschil is dat er gewoon een verschil in interpretatie is.

Zoals ik al zei, als je code overloopt (bv. een for-lus met enkele tientallen lijnen code, die methodes uit een andere klasse gaan gebruiken, etc.) moet je er van uit kunnen gaan dat die lus altijd x aantal keer zal uitgevoerd worden.

Laat dat de regel zijn, en een for met slechts 3 lijntjes de uitzondering.

MilM · 11 mrt 2009

Parnakra zei:
Niet alle for- of while-lussen bestaan uit 3 regeltjes code.

En dat zouden geen persoonlijke voorkeuren moeten zijn, je kan alles wat je met een forlus kan doen ook met een whilelus doen, en vice versa. Het grote verschil is dat er gewoon een verschil in interpretatie is.

Zoals ik al zei, als je code overloopt (bv. een for-lus met enkele tientallen lijnen code, die methodes uit een andere klasse gaan gebruiken, etc.) moet je er van uit kunnen gaan dat die lus altijd x aantal keer zal uitgevoerd worden.

Laat dat de regel zijn, en een for met slechts 3 lijntjes de uitzondering.

In een lus van veel regels, kan een paar regels extra geen kwaad. Maar in een kleine lus vind ik dit net juist minder leesbaar. Dat het in grote blokken verwaarloosbaar is en daarmee beter, doet er niet toe.
Dit klinkt alsof je kleine blokken minder leesbaar gaat maken om een consistent gebruik van 'while' te hebben bij grotere blokken. Je kunt hier over de voor/nadelen discussiëren.

Welk stuk code vind jij hier het meest leesbaar?

Ik vind het dan ook overdreven om iemand hierop te pakken in dit voorbeeld.

while en for lus zijn exact hetzelfde. Net zoals ik in de while lus een boolean gebruik, zou ik daar ook een break of return kunnen gebruiken.
Ik zou ook ipv een return in de for lus, een extra boolean als voorwaarde hebben kunnen meegeven.

Als jullie bij een for lus ervan uitgaan, dat de size van een collectie de enige voorwaarde is en dan niet controleren op andere voorwaardes tussen de haakjes (zoals hieronder), dan ligt dit aan jullie eerder dan aan slecht programmeren van de auteur.

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 de haakskes ipv een return of break statement.

For-lus versie:

Code:

boolean temp = false;
for(int i=0; i < collec.size() && !temp; i++){
	if(collec.equals("test"))
		temp = true;
}
return temp;

edit: ik beweer niet dat een for lus daarom beter is, ik vind het gewoon wat ver gaan om te doen alsof dit zo slecht programmeren is ...

Parnakra · 11 mrt 2009

MilM zei:
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.

Parnakra zei:
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. =/

Cycloon · 11 mrt 2009

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

MilM · 11 mrt 2009

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.

Cycloon · 11 mrt 2009

MilM zei:
Btw, het was niet "mijn" code hé Het was iemand anders die dat gepost had.

Ja natuurlijk, had er ff niet bij stilgestaan

Kemblin · 12 mrt 2009

Cycloon zei:
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 :oink:

Gurdt · 12 mrt 2009

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

Gurdt · 12 mrt 2009

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

eniac · 12 mrt 2009

Gurdt zei:
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/book/html/apas04.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.

forloRn_ · 12 mrt 2009

Ik zie daar nuttige dingen in staan, ik zie daar ook regelrechte stinkers in staan:

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:

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.

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

eniac · 12 mrt 2009

forloRn_ zei:
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.

Archief - [JAVA] Static reference in a non-static method

Kemblin

Legacy Member

Ice

Legacy Member

Bubbling Zombie

Legacy Member

Cycloon

Legacy Member

eniac

Legacy Member

MilM

Legacy Member

Parnakra

Legacy Member

MilM

Legacy Member

Parnakra

Legacy Member

MilM

Legacy Member

Parnakra

Legacy Member

Cycloon

Legacy Member

MilM

Legacy Member

Cycloon

Legacy Member

Kemblin

Legacy Member

Gurdt

Legacy Member

Gurdt

Legacy Member

eniac

Legacy Member

forloRn_

Legacy Member

eniac

Legacy Member