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

Ice · 12 mrt 2009

eniac zei:
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?

forloRn_ · 12 mrt 2009

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

eniac zei:
Point stands: hoe ga je weten waar de NPE zit? Die regel dient specifiek daarvoor.

Debuggen?

eniac · 12 mrt 2009

Ice zei:
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;
}

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

forloRn_ · 12 mrt 2009

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

eniac · 12 mrt 2009

Maar zoals ik al zei, is het zeer situatie-afhankelijk of je überhaupt een foutmelding aan de gebruiker wil tonen. Dat beslis je zelf.

MilM · 12 mrt 2009

Mja, het is niet altijd zo dat uw programma vastloopt na een foutmelding en dan kan het inderdaad een business beslissing zijn om de gebruiker niets te laten weten van die foutmelding.

Of denk maar aan een service die staat te draaien.
Dan wil je niet altijd dat de service stopt door een bepaalde error of dat er een popup te voorschijn komt.

forloRn_ · 12 mrt 2009

Het hoeft toch niet vast te lopen? Wat ga je je gebruiker dan wél tonen, een verkeerd resultaat?

Moto · 12 mrt 2009

Wat ga je je gebruiker dan wél tonen, een verkeerd resultaat?

komaan zeg effe lezen heh

, ->

Of denk maar aan een service die staat te draaien

Nachtelijk services die draaien, bij mijn weten zit der 's nachts gene gebruiker aan die server om popups weg te klikken

eniac · 12 mrt 2009

Eerst: zie reply boven mij

forloRn_ zei:
Het hoeft toch niet vast te lopen? Wat ga je je gebruiker dan wél tonen, een verkeerd resultaat?

Je resultaat zelf hoeft toch niet in se verkeerd te zijn?

Als je nu bijvoorbeeld puur voor statistische redenen iets wegschrijft naar DB dat niets te maken heeft met je business en dat niet van levensbelang is, dan wil je toch echt niet dat je gebruiker geen deftig antwoord krijgt? En dat er iets fout ging in de statistieken hoeft je gebruiker echt niet te weten.

forloRn_ · 12 mrt 2009

Ik ga er wel van uit dat de gemiddelde exception net iets ernstiger is dan het niet kunnen onderhouden van statistieken. Hoe dan ook, ik had beter verwacht van een webpagina die over goede programmeergewoontes gaat.

Cycloon · 12 mrt 2009

Wel grappig om te zien hoe sommige mensen met de meest vreemde codes proberen om hun gelijk te halen, terwijl de meeste stijlconventies gesteund worden door de meest bekende en beste programmeurs die er zijn. Het zijn zij ook meestal die ze opgesteld hebben.

Dat een taal wel ondersteuning geeft voor meerdere returns, breaks, goto's wil niet zeggen dat je ze mag gebruiken als je eens zin hebt.

Ook kunnen veel voorbeelden die hier getoond worden enorm versimpeld worden als er een beetje aan goed ontwerp gedaan wordt:

Code:

double getPayAmount() {
	if (_isDead) return deadAmount();
	if (_isSeparated) return separatedAmount();
	if (_isRetired) return retiredAmount();
	return normalPayAmount();
};

Statepattern anyone?

Code:

double getPayAmount() {
	return stateObject.PayAmount();
};

Vanaf je met een hele hoop if's komt te zitten kan je meestal zeggen dat je ontwerp slecht is.

eniac · 12 mrt 2009

forloRn_ zei:
Ik ga er wel van uit dat de gemiddelde exception net iets ernstiger is dan het niet kunnen onderhouden van statistieken.

Wat heeft de "gemiddelde exception" hier nu in godsnaam mee te maken?

De "gemiddelde exception" zal je anders afhandelen dan dit, maar dat wil niet zeggen dat dit geen valide gebruik kan zijn. Punt is dat je geen lege catch-blocks schrijft, hetgeen in het catch-block staat is business-specifiek en daarover kunnen we hier moeilijk een boompje opzetten.

Moto · 12 mrt 2009

Statepattern anyone?

Over-Designed anyone?

forloRn_ · 12 mrt 2009

eniac zei:
Wat heeft de "gemiddelde exception" hier nu in godsnaam mee te maken?

De "gemiddelde exception" zal je anders afhandelen dan dit, maar dat wil niet zeggen dat dit geen valide gebruik kan zijn. Punt is dat je geen lege catch-blocks schrijft, hetgeen in het catch-block staat is business-specifiek en daarover kunnen we hier moeilijk een boompje opzetten.

Kalm, kalm. Mijn punt is dat hij guidelines geeft waarvan je verwacht dat je ze in veel (de meeste) gevallen dient te gebruiken. Nu ondergraaft hij al direct één van zijn richtlijnen door een uitzondering als voorbeeld te geven. Ben jij soms al veel IOExceptions en SQLExceptions tegengekomen die niet fataal waren?

Als hij "// handle exception" in dat catch-block had gezet, was er geen probleem. In godsnaam zeg.

taLa. · 12 mrt 2009

Wat een fanatieke regeltjesaanhangers hier allemaal zeg :oink:

Als ge dergelijke lijsten van regeltjes tot op de letter begint te volgen zijt ge zelf fout bezig. Dergelijke regeltjes zijn precies zoals met de bijbel: ge moet ten eerste sowieso al 't gezond verstand hebben om ze voor uzelf te kunnen opbrengen, en ge moet ten tweede het idee erachter interpreteren in plaats van ze hersenloos letterlijk te volgen (en aan andere mensen op te dringen).

In die lijst die hiernet gepost werd staat ook fameuze bullshit ze. Onder andere:

Stephan Janssen de superprogrammeur zei:
Avoid performing equality operations on boolean operands. You should not use true and false literals in conditional clauses. By following this rule, you save some byte code instructions in the generated code and improve performance. In most situations, you also improve readability of the program.

WRONG

Code:

boolean isLoaded = true; if (isLoaded == true) { // ... }

RIGHT

Code:

boolean isLoaded = true; if (isLoaded) { // ... }

Als ge niet inziet wat er daar mis mee is, heb'k slecht nieuws voor u.

eniac · 12 mrt 2009

forloRn_ zei:
Kalm, kalm. Mijn punt is dat hij guidelines geeft waarvan je verwacht dat je ze in veel (de meeste) gevallen dient te gebruiken. Nu ondergraaft hij al direct één van zijn richtlijnen door een uitzondering als voorbeeld te geven.

Hij ondergraaft niets. Hij zegt dat je geen lege catch-blocks mag zetten en geeft een volledig correct voorbeeld daarvoor. Ik zie je probleem niet.

taLa. zei:
Als ge dergelijke lijsten van regeltjes tot op de letter begint te volgen zijt ge zelf fout bezig.

Tot je ant/maven buildscripts hebt met checkstyle plugins waarbij de builds falen als uw code niet deftig geformatteerd is volgens de regels. Overall gezien maak je zo gewoon deftige gevormde code.

In die lijst die hiernet gepost werd staat ook fameuze bullshit ze. Onder andere:
Als ge niet inziet wat er daar mis mee is, heb'k slecht nieuws voor u.

En wat is daar bullshit aan? Gebruik jij zelf "zetuwbooleanhier == true"?

Of heb je het over het feit dat die boolean daarvoor op true gezet wordt? Als je niet doorhebt dat het daar niet over gaat en dat die boolean daar gewoon wordt gezet om er geen uit de lucht te moeten trekken, dan heb ik slecht nieuws voor u.

Stephan Janssen de superprogrammeur

Je hebt werkelijk geen idee he?

Kemblin · 12 mrt 2009

Cycloon zei:
Wel grappig om te zien hoe sommige mensen met de meest vreemde codes proberen om hun gelijk te halen, terwijl de meeste stijlconventies gesteund worden door de meest bekende en beste programmeurs die er zijn. Het zijn zij ook meestal die ze opgesteld hebben.

Dat een taal wel ondersteuning geeft voor meerdere returns, breaks, goto's wil niet zeggen dat je ze mag gebruiken als je eens zin hebt.

Het voorbeeld wat ik gaf was niet vreemd tot ik het volgens jouw richtlijnen moest schrijven. Je hebt het trouwens nog nergens weerlegd...

Nog een leuke

Code:

public static double doe_iets(double a, double b) {
	if (a > b)
		return a;
	else if(a < b)
		return b;
	return Math.floor(a);
}

vs

Code:

public static double doe_iets(double a, double b) {
	double result;
	if (a > b)
		result = a;
	else if (a < b)
		result = b;
	else
		result = Math.floor(a);
	return result;
}

trouwens hier staan ook een aantal tegenargumenten.

MilM · 12 mrt 2009

Wat doet die "return Math.floor(a);" daar?

En wat doet dit?

Code:

if(result != a && result != b)
		result = Math.floor(a);

Ik ben niet goed mee eigenlijk

taLa. · 12 mrt 2009

eniac zei:
En wat is daar bullshit aan? Gebruik jij zelf "zetuwbooleanhier == true"?

Of heb je het over het feit dat die boolean daarvoor op true gezet wordt? Als je niet doorhebt dat het daar niet over gaat en dat die boolean daar gewoon wordt gezet om er geen uit de lucht te moeten trekken, dan heb ik slecht nieuws voor u.

Wat daar bullshit aan is is dat de compiler slim genoeg is om in te zien dat beiden identiek zijn, en dus identieke bytecode zal genereren. Het hele argument dat hij aangeeft van er performance mee te winnen en er bytecode mee uit te sparen is dikke zever.

Mijn hele punt is da ge een beetje kritisch moet zijn over die regels en ze interpreteren naargelang uw eigen context. Natuurlijk, als het u opgelegd wordt met bv. een dergelijke maven plugin kunt ge ni anders he

Verder ben ik het grondig eens met wat er gezegd wordt op de pagina waar Kemblin naar linkt:

Most programmers probably support the idea that simple readable code in more important than following any arbitrary rule. If coding to achieve a single return means complicating the code, then it's a mistake.

En dat geldt voor bijna al die regels: als ge u in bochten moet wringen of uw code moet bloaten om toch maar aan de regeltjes te voldoen, zijt ge fout bezig.

Kemblin · 12 mrt 2009

MilM zei:
Wat doet die "return Math.floor(a);" daar?

die Math.floor doet niks specifiek eigenlijk, maar dat was gewoon om nog een extra operatie toe te voegen.

MilM zei:
En wat doet dit?

Code:

if(result != a && result != b) result = Math.floor(a);

Ik ben niet goed mee eigenlijk

ja dat had ook gewoon eenvoudigweg een else result =Math.floor(a) kunnen zijn, maar het punt is nu al wel duidelijk hoop ik. Tgaat dus om die extra variabelen.

Op die site staat hetzelfde voorbeeld, maar dan iets duidelijker

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

Ice

Legacy Member

forloRn_

Legacy Member

eniac

Legacy Member

forloRn_

Legacy Member

eniac

Legacy Member

MilM

Legacy Member

forloRn_

Legacy Member

Moto

Legacy Member

eniac

Legacy Member

forloRn_

Legacy Member

Cycloon

Legacy Member

eniac

Legacy Member

Moto

Legacy Member

forloRn_

Legacy Member

taLa.

Legacy Member

eniac

Legacy Member

Kemblin

Legacy Member

MilM

Legacy Member

taLa.

Legacy Member

Kemblin

Legacy Member