[Java] Kleine vraag, ingewikkelde instructie.

[Verwijderd]

code:

node = ( node.left != null) ? node.left : node.right;

Ik zag al staan dat deze constructie zoveel mogelijk vermeden moet worden, maar ik kom hem steeds tegen in mijn boek. Kan iemand mij vertellen wat deze constructie precies doet.

[ Voor 5% gewijzigd door Verwijderd op 10-03-2011 20:56 ]

[Shadoxfix]

Dit is toch gewoon een if statement in een variable?

Oftewel:
als node.left niet gelijk is aan null.
Dan is node = node.left
Anders is het node = node.right.

(Hier spreekt een beginnende java programmeur correcties zijn welkom)

Waarom dit vermeden zou moeten worden weet ik niet.
In mijn boek word het ook vaak gebruikt.

[ Voor 19% gewijzigd door Shadoxfix op 10-03-2011 20:59 ]

[krvabo]

Dat is een verkort if-statement.

if node.left != null -> node = node.left
else node = node.right;

[Ansur]

Zoek eens op ternaire operator. De reden dat dit zogezegd vermeden moet worden is voor de leesbaarheid. Het kan wel 'ingewikkeld' worden wanneer je geneste ternaire operators gebruikt.

Imo. is dit net een mooie constructie, persoonlijk waarschijnlijk?

[ Voor 61% gewijzigd door Ansur op 10-03-2011 21:00 ]

[beany]

Zelfde als

code:

if ( node.left != null )
   node = node.left;
else
   node = node.right;

En deze constructie hoef je helemaal niet te vermijden. Het maakt code soms overzichtelijker.

[l1dert]

Ansur schreef op donderdag 10 maart 2011 @ 20:59:
Zoek eens op ternaire operator. De reden dat dit zogezegd vermeden moet worden is voor de leesbaarheid. Het kan wel 'ingewikkeld' worden wanneer je geneste ternaire operators gebruikt.

Imo. is dit net een mooie constructie, persoonlijk waarschijnlijk?

Schrijf wel snel, maar verhoogd de leesbaarheid van de code niet echt. Zeker als je code van een ander voorgeschoteld krijgt lees je er al snel overheen wat er nu precies staat. Persoonlijk vind ik het zelf ook niet fijn om te gebruiken in mijn eigen code. En in de coding guidelines op het werk staat het gelukkig ondertussen ook als don't opgenomen.

[Woy]

Zoals inderdaad gezegd is dat een ternary operator, en dat is dus gewoon een operator die aan de hand van een expressie een van de 2 argumenten terug geeft. Ik zie niet in waarom je deze constructie zou moeten vermijden. Natuurlijk moet je er wel mee oppassen dat het leesbaar blijft. Als je deze constructie meerdere malen gaat nesten dan kan het inderdaad wat onleesbaar worden. Maar voor alle taal-constructies geld dat er gevallen zijn waar je het wel voor wil gebruiken en waar niet.

Ik gebruik de ternary operator in ieder geval vrij vaak, en zolang je ook goed oplet hoe de formatting van je code is, vind ik het zeker bijdragen aan beter leesbare en minder vebose code.

[YopY]

Stiekem had ik vandaag net een bug omdat ik het 'if' en 'else' gedeelte hiervan omdraaide, .

Java:

public EenOfAnderObject doeIets() {
    List<EenOfAnderObject> lijst = haalIetsOp();
    return (list.size() == 0) ? list.get(0) : null;
}

Vandaar de waarschuwing. Ternary operator zou je alleen in de meest eenvoudige en overduidelijke contexts moeten gebruiken. Bij meer dan één statement, bijvoorbeeld, kun je al beter een gewone if / else uitschrijven.

[Verwijderd]

Bedankt allemaal!
Gewoon een verkorte if-else dus.

[Gamebuster]

YopY schreef op donderdag 10 maart 2011 @ 21:20:
Stiekem had ik vandaag net een bug omdat ik het 'if' en 'else' gedeelte hiervan omdraaide, .

Heel irritant, heb ik ook paar keer gehad

[Woy]

YopY schreef op donderdag 10 maart 2011 @ 21:20:
Stiekem had ik vandaag net een bug omdat ik het 'if' en 'else' gedeelte hiervan omdraaide, .

Java:

public EenOfAnderObject doeIets() {
    List<EenOfAnderObject> lijst = haalIetsOp();
    return (list.size() == 0) ? list.get(0) : null;
}

Vandaar de waarschuwing. Ternary operator zou je alleen in de meest eenvoudige en overduidelijke contexts moeten gebruiken. Bij meer dan één statement, bijvoorbeeld, kun je al beter een gewone if / else uitschrijven.

Maar met een if-else kan je de statements net zo goed per ongeluk omdraaien. Ik ben het er wel mee eens dat je het statement wel duidelijk moet houden en niet te complex moet maken, maar dat geld eigenlijk net zo goed voor if-else statements.

[Mammon]

De ternary operator is helemaal leuk in combinatie met autoboxing. Wat is hier de uitkomst van:

Java:

Number num = (true) ? new Integer(5) : new Double(6.0);
System.out.println(num);

spoiler:

5.0

[.oisyn]

Als er niet geautoboxed werd dan was de expressie sowieso ongeldig.
.edit: hmm, blijkbaar niet in Java.

[ Voor 21% gewijzigd door .oisyn op 10-03-2011 22:11 ]

[Niemand_Anders]

Bij ons is de ternary operator niet verboden, alleen geven wij wel aan dat er terughoudend met de operator dient te worden omgegaan en dat de expressie zonder verdere context te lezen moet zijn.

Wel hebben wij als regel dat de ternary operator niet in een argumenten lijst gebruikt mag worden.

C#:

//vermijden
string.Format("Geslacht: {0}", dossier.PrimaryApplicant.IsMale ? "Man" : "Vrouw");


//leesbaarder
string gender = dossier.PrimaryApplicant.IsMale ? "Man" : "Vrouw");
string.Format("Geslacht: {0}", gender);


//minder leesbaar (maar doet hetzelfde)
string gender = string.Empty;
if (dossier.PrimaryApplicant.IsMale)
  gender = "Man";
else
  gender = "Vrouw";
string.Format("Geslacht: {0}", gender);

Maar zoals met alle instrumenten welke je tot je beschikking hebt, moet je ze wel op het juiste moment gebruiken.

[RayNbow]

Mammon schreef op donderdag 10 maart 2011 @ 21:52:
De ternary operator is helemaal leuk in combinatie met autoboxing. Wat is hier de uitkomst van:

Java:

Number num = (true) ? new Integer(5) : new Double(6.0);
System.out.println(num);

spoiler:

5.0

Ah, deze komt (in iets gewijzigde vorm) ook voor in Advanced Topics in Programming Languages: Java Puzzlers

[Woy]

Niemand_Anders schreef op donderdag 10 maart 2011 @ 23:28:
Bij ons is de ternary operator niet verboden, alleen geven wij wel aan dat er terughoudend met de operator dient te worden omgegaan en dat de expressie zonder verdere context te lezen moet zijn.

Wel hebben wij als regel dat de ternary operator niet in een argumenten lijst gebruikt mag worden.

C#:

//vermijden
string.Format("Geslacht: {0}", dossier.PrimaryApplicant.IsMale ? "Man" : "Vrouw");


//leesbaarder
string gender = dossier.PrimaryApplicant.IsMale ? "Man" : "Vrouw");
string.Format("Geslacht: {0}", gender);


//minder leesbaar (maar doet hetzelfde)
string gender = string.Empty;
if (dossier.PrimaryApplicant.IsMale)
  gender = "Man";
else
  gender = "Vrouw";
string.Format("Geslacht: {0}", gender);

Maar zoals met alle instrumenten welke je tot je beschikking hebt, moet je ze wel op het juiste moment gebruiken.

Op zich inderdaad redelijke regels. Op zich vind ik in dit geval de eerste variant ook gewoon goed leesbaar, maar het introduceren van een extra variabele kan het in veel situaties inderdaad een stuk duidelijker maken, en dan kan je dat inderdaad maar beter gewoon als stelregel nemen

Mammon schreef op donderdag 10 maart 2011 @ 21:52:
De ternary operator is helemaal leuk in combinatie met autoboxing. Wat is hier de uitkomst van:

De volgende code zal toch hetzelfde resultaat hebben neem ik aan? Beide operanden moeten immers van hetzelfde type zijn, en dus zal er een widening conversion toegepast moeten worden?

Java:

Number num = (true) ? 5 : 6.0;
System.out.println(num);

[ Voor 15% gewijzigd door Woy op 11-03-2011 09:02 ]

[Matis]

Niemand_Anders schreef op donderdag 10 maart 2011 @ 23:28:
Bij ons is de ternary operator niet verboden, alleen geven wij wel aan dat er terughoudend met de operator dient te worden omgegaan en dat de expressie zonder verdere context te lezen moet zijn.

Wel hebben wij als regel dat de ternary operator niet in een argumenten lijst gebruikt mag worden.

Laten we ook hopen dat in jullie afspraken staat dat er altijd accolades rond een if, else etc. statement moeten

[YopY]

Woy schreef op donderdag 10 maart 2011 @ 21:24:
[...]

Maar met een if-else kan je de statements net zo goed per ongeluk omdraaien. Ik ben het er wel mee eens dat je het statement wel duidelijk moet houden en niet te complex moet maken, maar dat geld eigenlijk net zo goed voor if-else statements.

Da's waar, maar (in mijn ervaring) is dat toch iets makkelijker bij ternary operators, ivm het ontbreken van woorden. if / else is toch iets duidelijker dan ? / :

En dan willen ze ook nog ?: in Java proppen .

[.oisyn]

Matis schreef op vrijdag 11 maart 2011 @ 09:16:
[...]

Laten we ook hopen dat in jullie afspraken staat dat er altijd accolades rond een if, else etc. statement moeten

Wat is dat nou voor een onzin. Dat "laten we hopen" bedoel ik dan. Het blijft gewoon een subjectieve afspraak.

Woy schreef op vrijdag 11 maart 2011 @ 09:00:
De volgende code zal toch hetzelfde resultaat hebben neem ik aan? Beide operanden moeten immers van hetzelfde type zijn, en dus zal er een widening conversion toegepast moeten worden?

Java:

Number num = (true) ? 5 : 6.0;
System.out.println(num);

Maar zonder autoboxing is er een conversie naar Number mogelijk voor beide operanden, en dan blijft de uitkomst dus een Integer, en geen Double.

[ Voor 48% gewijzigd door .oisyn op 11-03-2011 10:16 ]

[Niemand_Anders]

Matis schreef op vrijdag 11 maart 2011 @ 09:16:
[...]

Laten we ook hopen dat in jullie afspraken staat dat er altijd accolades rond een if, else etc. statement moeten

De afspraken welke wij hebben afgesproken hebben als voornaamste doel om de leesbaarheid te verhogen.

C#:

if (true)   
  Console.WriteLine("Hello world");
else
  Console.Writeline("You're never gonna see this..");



if (true)
{
  Console.WriteLine("Hello world");
}
else
{
  Console.Writeline("You're never gonna see this..");
}

Bij ons geeft Resharper zelfs een suggestie om de accolades te verwijderen.
De accolades zijn bij ons alleen verplicht als er meerdere statements in een if of else blok moeten komen..

[Amras]

Niemand_Anders schreef op vrijdag 11 maart 2011 @ 10:53:
[...]
De accolades zijn bij ons alleen verplicht als er meerdere statements in een if of else blok moeten komen..

Wat vrij logisch is, want zonder accolades gaat dat niet lukken.

Ik gebruik eigenlijk alleen geen accolades bij dit soort code:

C#:

if (foo != null)
    foo.Bar = 1;

of

C#:

if (foo == null)
    throw new ArgumentNullException("foo");

Bij meer ingewikkeldere expressies vind ik het er vaak rommeliger uitzien, maar bij korte statements staat het wel netter.

[ Voor 10% gewijzigd door Amras op 11-03-2011 11:07 ]

[SPee]

Totdat je moet refactoren, niet goed oplet en een 2e statement aan de if denkt toe te voegen.

Java:

String bla = null;
if( true )
  bla = "true";
  System.out.println( bla.length() );

// NullPointerException
vs

Java:

String bla = null;
if( true ){
  bla = "true";
  System.out.println( bla.length() );
}

[Nick_S]

Dat geeft geen NPE hoor. Maar ik ben het er wel mee eens, ook al doet autoformatting tegenwoordig ook een hoop om dit soort dingen tegen te gaan.

[.oisyn]

Euh, wel hoor.

[RayNbow]

Er staat "if (true)"?

[Hydra]

Ansur schreef op donderdag 10 maart 2011 @ 20:59:
Zoek eens op ternaire operator. De reden dat dit zogezegd vermeden moet worden is voor de leesbaarheid. Het kan wel 'ingewikkeld' worden wanneer je geneste ternaire operators gebruikt.

Zolang je ze niet nest vind ik het prima leesbaar en onzin dat ze 'vermeden' zouden moeten worden. Dit hoor je als Java dev gewoon te snappen.

Niemand_Anders schreef op vrijdag 11 maart 2011 @ 10:53:
De afspraken welke wij hebben afgesproken hebben als voornaamste doel om de leesbaarheid te verhogen.

Ik heb me een keer uren blind zitten staren op iets als dit:

code:

if(ietsDatInDeMeesteGevallenFalseIs);
   eenMethode();

En dan maar niet uit kunnen vogelen waarom die eenMethode() dus altijd uitgevoerd wordt. Ben sindsdien een groot voorstander van het altijd gebruiken van accolades.

[ Voor 37% gewijzigd door Hydra op 11-03-2011 12:05 ]

[Niemand_Anders]

SPee schreef op vrijdag 11 maart 2011 @ 11:16:
Totdat je moet refactoren, niet goed oplet en een 2e statement aan de if denkt toe te voegen.

Maar een verkeerde refactoring behoor je af te vangen met je unit tests (code coverage). En ja als je niet goed oplet zal er wel meer verkeerd gaan. Programmeren is een serieuze aangelegenheid en dient derhalve met volle concentratie uitgevoerd te worden. In mijn team is in elk geval geen plaats voor lieden welke routinematig code inkloppen en verder niet nadenken waar ze mee bezig zijn en of het allemaal wel zo logisch is wat ze aan het doen zijn.

Ik heb me een keer uren blind zitten staren op iets als dit:

En ja een punt-komma plaatsen na een if statement heeft verder weinig met coding standaards te maken en ook als je de accolades wel gebruikt kan zo'n fout nog steeds voorkomen met hetzelfde resultaat.

C#:

if (if(ietsDatInDeMeesteGevallenFalseIs);
{
   eenMethode();
}

Accolades markeren alleen het begin en einde van een instructie blok en mogen daarom ook los gebruikt worden. Het is verder nutteloos, maar je compiler zal er niet over vallen.

[Jeffroiscool]

Gamebuster schreef op donderdag 10 maart 2011 @ 21:22:
[...]

Heel irritant, heb ik ook paar keer gehad

Dat had ik gister nog, ik facepalmde hard toen ik er na 1 uur debuggen achter kwam

[.oisyn]

RayNbow schreef op vrijdag 11 maart 2011 @ 12:01:
Er staat "if (true)"?

Oh ja

[Hydra]

Niemand_Anders schreef op vrijdag 11 maart 2011 @ 12:24:
Accolades markeren alleen het begin en einde van een instructie blok en mogen daarom ook los gebruikt worden. Het is verder nutteloos, maar je compiler zal er niet over vallen.

Doh

Je hebt helemaal gelijk. Ik zou zweren dat Eclipse daar tenminste een warning op gaf maar dat kan ook gewoon...

[.oisyn]

Ik zou de warning verwachten op de empty statement na de if, niet zozeer op het gebruik van accolades erna.

[Verwijderd]

Ik heb wel een druk topic geopend zo