[ALG] Waarom zijn if statements zonder body toegestaan?

quote:

Herko_ter_Horst schreef op dinsdag 22 juli 2008 @ 11:41:
[...]

Nee, eerder:
code:

for(;doSomethingWithUglySideEffect(););

De reden dat het toegestaan is, is volgens mij wat Janoz hierboven zegt puur de syntax-definitie (stukje BNF):
code:

if_statement 
      ::= 
      "if" "(" expression ")" statement
      ..... // blah, blah

statement 
      ::= 
      ( expression ";" )
      |     ...... // blah, blah
      | ( ";" )

; is dus een legaal statement. Een uitzondering maken voor situaties waarin dat (waarschijnlijk) niet is wat je wilt is het mindere kwaad in zo'n geval (wil je dat wel, dan verhoog je "onnodig" de complexiteit van de syntax). Het heeft dus NIET tot doel het soort vieze constructies waar dit topic inmiddels vol mee staat mogelijk te maken.

Volgende stukje vind ik niet echt een ranzige manier om danwel de eerste index i te vinden met a[i] <= 0,
danwel uit het array te lopen met i == N:
C:

1	for (i=0; (i<N) && (a[i] > 0); i++) ;

Ik moet zeggen dat de coding standard die wij hanteren wel een explicitiete empty statement vereist:
C:

1	for (i=0; (i<N) && (a[i] > 0); i++) { /* empty */ };

Zo kan het statisch gecheckt worden en is duidelijk dat e.e.a. bedoeld is.

quote:

pkuppens schreef op woensdag 23 juli 2008 @ 13:37:
[...]


Volgende stukje vind ik niet echt een ranzige manier om danwel de eerste index i te vinden met a[i] <= 0,
danwel uit het array te lopen met i == N:
C:

1	for (i=0; (i<N) && (a[i] > 0); i++) ;

Ik moet zeggen dat de coding standard die wij hanteren wel een explicitiete empty statement vereist:
C:

1	for (i=0; (i<N) && (a[i] > 0); i++) { /* empty */ };

Zo kan het statisch gecheckt worden en is duidelijk dat e.e.a. bedoeld is.

Een while loop met boolean vind ik toch duidelijker en netter
code:

boolean found = false;
int index = 0;
while(!found)
{
    if(a[index++]>0) found = true;
}

Liever iets meer typen dan kortere onduidelijke code

quote:

farlane schreef op woensdag 23 juli 2008 @ 14:35:
[...]


En het feit dat jouw code alle elementen doorloopt tot a.length maakt niets uit?

Jawel, wat er eerst stond was ook niet de bedoeling, ik heb het aangepast

Haan wijzigde dit bericht 23-07-2008 14:41 (18%)

quote:

Haan schreef op woensdag 23 juli 2008 @ 14:15:
Liever iets meer typen dan kortere onduidelijke code

En het feit dat jouw code alle elementen doorloopt tot a.length maakt niets uit?

Is gewoon heel simpel...

Een lege body is in een aantal gevallen een valide constructie. Ik kan me voorstellen dat een if statement zelf een dusdanig side effect heeft dat een body niet noodzakelijk is.

In C is het volkomen normaal om te schrijven:
code:

FILE fp
//doe iets waardoor je misschien wel of niet een file pointer hebt.
if(fp == null || fclose(fp));

Waarom dat er ooit ingekomen is weet ik niet. Maar mijns inziens is het van belang dat een programmeer taal niet voor interpretatie vatbaar is. Dat er dan een paar edge cases zijn (al dan niet met reden), lig ik niet wakker van.

En wat natuurlijk ook mogelijk is, is het definiëren van een functie in een interface
PHP:

1 2 3

<?php interface iExample {    public function mijnFunctie($szVar); } ?>

quote:

The - DDD schreef op woensdag 23 juli 2008 @ 14:39:
Is gewoon heel simpel...

Een lege body is in een aantal gevallen een valide constructie. Ik kan me voorstellen dat een if statement zelf een dusdanig side effect heeft dat een body niet noodzakelijk is.

In C is het volkomen normaal om te schrijven:
code:

FILE fp
//doe iets waardoor je misschien wel of niet een file pointer hebt.
if(fp == null || fclose(fp));

Waarom dat er ooit ingekomen is weet ik niet. Maar mijns inziens is het van belang dat een programmeer taal niet voor interpretatie vatbaar is. Dat er dan een paar edge cases zijn (al dan niet met reden), lig ik niet wakker van.

Heb je het topic gelezen? Een voorbeeld als dit is al diverse keren voorbij gekomen en volgens mij zijn de meeste posters het er over eens dat dit niet de duidelijkste manier om zoiets op te schrijven. Ik vind het veel duidelijker om te schrijven:
code:

if(fp != null) {
 fclose(fp);
}

Nu maak je m.i. gebruik van maar liefst drie impliciete eigenschappen bij elkaar die extra mentale verwerkingskracht vergen om te snappen: short-circuit van boolean expressies, een leeg statement en het feit dat fpclose() blijkbaar een boolean retourneert (terwijl je daar verder niks mee doet).

Plus het feit dat je erg makkelijk over een leeg statement heen leest waardoor je kunt denken dat het eerstvolgende niet-lege statement wordt "beschermd" door de if.

Herko_ter_Horst wijzigde dit bericht 23-07-2008 14:59 (8%)

quote:

ZktaS schreef op woensdag 23 juli 2008 @ 14:48:
En wat natuurlijk ook mogelijk is, is het definiëren van een functie in een interface
PHP:

1 2 3

<?php interface iExample {    public function mijnFunctie($szVar); } ?>

Verkeerde topic?

quote:

ZktaS schreef op woensdag 23 juli 2008 @ 14:48:
En wat natuurlijk ook mogelijk is, is het definiëren van een functie in een interface
PHP:

1 2 3

<?php interface iExample {    public function mijnFunctie($szVar); } ?>

Maar dat heeft vrij weinig met het if-statement te maken hè

En volgens mij mag je het public keyword ook weglaten in een interface, omdat die sowieso altijd public methoden bevat. correct me if I'm wrong offcourse

quote:

pkuppens schreef op woensdag 23 juli 2008 @ 13:37:
[...]


Volgende stukje vind ik niet echt een ranzige manier om danwel de eerste index i te vinden met a[i] <= 0,
danwel uit het array te lopen met i == N:
C:

1	for (i=0; (i<N) && (a[i] > 0); i++) ;

Ik moet zeggen dat de coding standard die wij hanteren wel een explicitiete empty statement vereist:
C:

1	for (i=0; (i<N) && (a[i] > 0); i++) { /* empty */ };

Zo kan het statisch gecheckt worden en is duidelijk dat e.e.a. bedoeld is.

[ALG] Waarom zijn if statements zonder body toegestaan?

Om het topic een beetje on-topic en algemeen te houden: in Oracle PL/SQL is het niet toegestaan...onderstaande code compileert simpelweg niet:
code:

CREATE OR REPLACE PROCEDURE TEST IS

BEGIN
 IF (sysdate>to_date('16/09/1975','dd/mm/yyyy'))
 THEN

  END IF;
END;
/

Het is dus niet altijd zo dat een lege body een valide constructie is.

quote:

Herko_ter_Horst schreef op woensdag 23 juli 2008 @ 14:54:
Nu maak je m.i. gebruik van maar liefst drie impliciete eigenschappen bij elkaar die extra mentale verwerkingskracht vergen om te snappen: short-circuit van boolean expressies, een leeg statement en het feit dat fpclose() blijkbaar een boolean retourneert (terwijl je daar verder niks mee doet).

Volgens mij zijn short-circuit en het casten van een type naar een booleaanse waarde behoorlijk expliciet in C, als je daar geen gebruik van zou mogen maken omdat het onduidelijk zou zijn kun je 50% van de C software afschrijven.

Afgezien van dat zou ik deze manier ook niet kiezen in dit geval.

quote:

Haan schreef op woensdag 23 juli 2008 @ 14:15:
[...]

Een while loop met boolean vind ik toch duidelijker en netter
code:

boolean found = false;
int index = 0;
while(!found)
{
    if(a[index++]>0) found = true;
}

Liever iets meer typen dan kortere onduidelijke code

[...]

Jawel, wat er eerst stond was ook niet de bedoeling, ik heb het aangepast

Ik haal wel 2 serieuze bugs uit jouw programma.
1. als je array geen getal > 0 bevat loop je uit je array
2. je index met postfix geeft de gewenste waarde +1 terug.

Je bent nog wel even bezig met je code te tunen totdat die precies doet wat ik wilde, en dan heb je alsnog redelijk onleesbare code.

Dan heb ik liever mijn regel code met twee regels commentaar dan jouw code.

Maar toegegeven, mijn code maakt wel gebruik van wat C finesses en 15+ jaar ervaring, zoals dat de i++ niet meer wordt gedaan als de conditie niet meer geldig is. En reken maar dat het in die 15 jaar regelmatig niet meteen goed is gegaan.

Ook vind ik een for loop een betere keuze hier, omdat de bewijslast van de correctheid van het programma van een for-loop eenvoudiger is dan van een while loop.

Verder ging de originele vraag over if statements, en daarin kan ik me voorstellen dat je minder staat te springen om zij-effecten.

quote:

farlane schreef op woensdag 23 juli 2008 @ 15:11:
[...]


Volgens mij zijn short-circuit en het casten van een type naar een booleaanse waarde behoorlijk expliciet in C, als je daar geen gebruik van zou mogen maken omdat het onduidelijk zou zijn kun je 50% van de C software afschrijven.

Afgezien van dat zou ik deze manier ook niet kiezen in dit geval.

Een redelijk favoriete quote:
C combineert de snelheid van assembly met de leesbaarheid van assembly.

Maar ik was ook al met m'n for-loop in C teveel afgedwaald van de originele if in Java.

quote:

Herko_ter_Horst schreef op woensdag 23 juli 2008 @ 14:54:
[...]

Heb je het topic gelezen? Een voorbeeld als dit is al diverse keren voorbij gekomen en volgens mij zijn de meeste posters het er over eens dat dit niet de duidelijkste manier om zoiets op te schrijven. Ik vind het veel duidelijker om te schrijven:
code:

if(fp != null) {
 fclose(fp);
}

Nu maak je m.i. gebruik van maar liefst drie impliciete eigenschappen bij elkaar die extra mentale verwerkingskracht vergen om te snappen: short-circuit van boolean expressies, een leeg statement en het feit dat fpclose() blijkbaar een boolean retourneert (terwijl je daar verder niks mee doet).

Plus het feit dat je erg makkelijk over een leeg statement heen leest waardoor je kunt denken dat het eerstvolgende niet-lege statement wordt "beschermd" door de if.

Eens...

De enige reden die ik kan bedenken is dat het een syntax betreft die afgeleid is van C.

quote:

farlane schreef op woensdag 23 juli 2008 @ 15:11:
[...]
Volgens mij zijn short-circuit en het casten van een type naar een booleaanse waarde behoorlijk expliciet in C, als je daar geen gebruik van zou mogen maken omdat het onduidelijk zou zijn kun je 50% van de C software afschrijven.

Afgezien van dat zou ik deze manier ook niet kiezen in dit geval.

Dat was niet mijn punt: natuurlijk is het gedrag expliciet gedefinieerd ergens. Het punt is dat er gebruik wordt maakt van gedrag dat niet direct en triviaal afleesbaar is uit de code om iets korter op te kunnen schrijven. Het feit dat fclose() een int teruggeeft die gecast moet worden naar een boolean maakt het alleen maar lelijker (ik wist dat niet en ging er vanuit dat fclose() een boolean zou retourneren; in Java werkt deze constructie niet eens met een int). De bedoeling van de code raakt compleet ondergesneeuwd in de "slimme truukjes" van de programmeur.

Mijn "sanity check" is vaak om te proberen de code in natuurlijke taal voor te lezen (zoveel mogelijk). Leg dat naast wat je eigenlijk bedoelt met de code. Hoe meer de twee overeen komen, hoe groter de kans dat de code ook voor anderen duidelijk is.

Wat is het doel van de code:

quote:

als de file pointer een legale waarde bevat^A, sluit dan de file^B

Wat staat er in de oorspronkelijke code:

quote:

als fp null is⁽¹⁾, of anders⁽²⁾ als de aanroep van fclose(fp) true retourneert^{(3) (4)}, doe dan niks⁽⁵⁾

Wat staat er in de door mij geposte versie:

quote:

als fp niet null is⁽⁶⁾, roep dan fclose(fp) aan⁽⁷⁾

Mentale stappen voor de vertaling van natuurlijke taal naar code die je altijd zult moeten doorlopen:

A: 'legaal' betekent voor een file pointer "niet null"
B: een file sluiten gaat via de fclose() method op de file pointer

Mentale stappen bij het lezen van deze code:

1: het tegengestelde van A
2: ('anders' vergeet je gauw mee te nemen)
3. Als fclose() true teruggeeft? Maar fclose() geeft toch een int terug? Oh ja die wordt gecast...
4. B, als side-effect
5. Niks? Ja maar... Oh wacht, fclose() was de bedoeling...

vs.

6. A
7. B

Herko_ter_Horst wijzigde dit bericht 23-07-2008 18:08 (34%)

quote:

Herko_ter_Horst schreef op woensdag 23 juli 2008 @ 17:21:
(ik wist dat niet en ging er vanuit dat fclose() een boolean zou retourneren; in Java werkt deze constructie niet eens met een int).

Als je dit soort dingen niet weet van de taal waarin je werkt ben je wat mij betreft niet geschikt om je werk te doen. Sterker nog, er hoeft niet eens gecast te worden omdat de if-statement niet expliciet met bools werkt maar met 0 en niet 0.

PrisonerOfPain wijzigde dit bericht 23-07-2008 18:26 (14%)

quote:

PrisonerOfPain schreef op woensdag 23 juli 2008 @ 18:22:
[...]
Als je dit soort dingen niet weet van de taal waarin je werkt ben je wat mij betreft niet geschikt om je werk te doen. Sterker nog, er hoeft niet eens gecast te worden omdat de if-statement niet expliciet met bools werkt maar met 0 en niet 0.

C is dan ook niet de taal waarin ik werk Overigens is fopen() is geen onderdeel van de taal, maar een onderdeel van een standaard-library.

Uit jouw flame reactie begrijp ik dat het zeer onwaarschijnlijk is dat een C programmeur dit niet zou weten, maar het gaat ook niet om deze specifieke functie (je hebt de [ALG] prefix voor dit topic gezien, alsmede de voorbeeldcode in diverse talen in de rest van dit topic, neem ik aan?).

Het gaat om het aantal mentale stappen dat je moet maken om de code te overzien.

Dus bedankt voor het versterken van mijn punt: ook zonder die kennis (die NIETS met het op te lossen "probleem" te maken heeft) is "mijn" versie van dezelfde code duidelijk.

Herko_ter_Horst wijzigde dit bericht 23-07-2008 19:35 (25%)

quote:

Herko_ter_Horst schreef op woensdag 23 juli 2008 @ 19:15:
[...]

C is dan ook niet de taal waarin ik werk Overigens is fopen() is geen onderdeel van de taal, maar een onderdeel van een standaard-library.

Toch is het allebei onderdeel van dezelfde standaard . Verder is het natuurlijk onzin om te verwachtten dat je een willekeurig persoon op een project kan gooien en kan verwachtten 'ie er mee om kan gaan. Mijn punt was dus ook dat als je niets van een bepaalde omgeving af weet (dat kan de stdlib zijn, maar ook ZF, Lucene, Smalltalk of het bedrijfsframework) je simpelweg geen aannames kan maken over zulke statements in het programma.

quote:

Uit jouw flame reactie begrijp ik dat het zeer onwaarschijnlijk is dat een C programmeur dit niet zou weten, maar het gaat ook niet om deze specifieke functie (je hebt de [ALG] prefix voor dit topic gezien, alsmede de voorbeeldcode in diverse talen in de rest van dit topic, neem ik aan?).

Het gaat om het aantal mentale stappen dat je moet maken om de code te overzien.

Als programmeur (en zeker in C) dien je sowieso altijd op de hoede te zijn. Programmacode is dan ook geen simpel romannetje, maar een droge juridische tekst. Als je niet precies weet wat er staat heb je gewoon een probleem. Zelfs als je alles zo duidelijk en netjes mogelijk opschrijft heb je gewoon nog voor de hand liggende basiskennis nodig.

quote:

Dus bedankt voor het versterken van mijn punt: ook zonder die kennis (die NIETS met het op te lossen "probleem" te maken heeft) is "mijn" versie van dezelfde code duidelijk.

Het punt dat ik probeerde te maken was dan ook niet dat jou code op een willekeurige welke manier minder leesbaar was; het punt was dat je sowieso moet weten wat je aan het doen bent hoe eenvoudig het er dan ook uit ziet. Je vergiste je immers zelf ook

quote:

pkuppens schreef op woensdag 23 juli 2008 @ 16:25:
[...]


Ik haal wel 2 serieuze bugs uit jouw programma.
1. als je array geen getal > 0 bevat loop je uit je array
2. je index met postfix geeft de gewenste waarde +1 terug.
<knip>etc.

offtopic:
Het was ook maar een snel voorbeeldje, geen weldoordachte en uitvoerig geteste productiecode

quote:

Janoz schreef op dinsdag 22 juli 2008 @ 11:46:
nee, dat dacht ik even, maar ik heb net ff snel wat gechecked en dat blijkt niet zo te zijn.

In sommige talen kan dat wel:
JavaScript:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

function doSomething() {     alert('something');     return true; } function doSomethingElse() {     alert('something else');     return false; } function dontDoThis() {     alert('not doing this');     return true; } doSomething() && doSomethingElse() && dontDoThis();

quote:

Herko_ter_Horst schreef op woensdag 23 juli 2008 @ 17:21:
Dat was niet mijn punt: natuurlijk is het gedrag expliciet gedefinieerd ergens. Het punt is dat er gebruik wordt maakt van gedrag dat niet direct en triviaal afleesbaar is uit de code om iets korter op te kunnen schrijven.

Laten we voorop stellen dat in dit ( gemaakt ) voorbeeld ik het helemaal met je eens ben dat de versie die jij gebruikt veel duidelijker is.

Je haalt echter ook een tweetal eigenschappen aan die je mijns inziens als C programmeur ( het voorbeeld ging immers over een stukje C ) gewoon moet weten en herkennen.

quote:

Herko_ter_Horst schreef op woensdag 23 juli 2008 @ 17:21:
Mijn "sanity check" is vaak om te proberen de code in natuurlijke taal voor te lezen (zoveel mogelijk). Leg dat naast wat je eigenlijk bedoelt met de code. Hoe meer de twee overeen komen, hoe groter de kans dat de code ook voor anderen duidelijk is.

Die "sanity check" heb je m.i. weer direct omzeepgeholpen door 8 voetnoten in je quotes op te nemen die je bij normale code als comment had kunnen zetten bij de stukken code waar 't relevant voor is. Enne... o ja, voetnoot 6) is blijkbaar verdwenen...

quote:

farlane schreef op donderdag 24 juli 2008 @ 00:02:
[...]
Laten we voorop stellen dat in dit ( gemaakt ) voorbeeld ik het helemaal met je eens ben dat de versie die jij gebruikt veel duidelijker is.

Je haalt echter ook een tweetal eigenschappen aan die je mijns inziens als C programmeur ( het voorbeeld ging immers over een stukje C ) gewoon moet weten en herkennen.

Ok, daar ging het mij niet om (en ik ben zoals gezegd geen C programmeur). Natuurlijk ken je als programmeur de regels van de taal en weet je van standaard functies de betekenis en return value. Wat je weet c.q. kunt beredeneren en wat in 1 keer duidelijk is, zijn echter twee verschillende dingen.

quote:

Afterlife schreef op donderdag 24 juli 2008 @ 00:22:
[...]
Die "sanity check" heb je m.i. weer direct omzeepgeholpen door 8 voetnoten in je quotes op te nemen die je bij normale code als comment had kunnen zetten bij de stukken code waar 't relevant voor is. Enne... o ja, voetnoot 6) is blijkbaar verdwenen...

De sanity check bestaat uit de "quotes", hoe je de programmacode als "normale" zin leest. De voetnoten heb ik er bij gezet om aan te geven welke mentale stappen je tijdens het lezen van zo'n zin nog moet nemen om er achter te komen dat de zin inderdaad voldoet aan wat je bedoelt, of andersom: om erachter te komen wat de bedoeling is/was.

Het lijkt mij duidelijk dat het eerste voorbeeld veel verder van de bedoeling van de code af ligt dan het tweede. Dat is voor mij het criterium om voor een bepaalde manier van opschrijven te kiezen.

Ja, natuurlijk kun je het coderen als in het eerste voorbeeld. Werkt het minstens net zo goed? Ja. Is het minder typ-werk? Ja. Is het duidelijker? Nee.

quote:

crisp schreef op woensdag 23 juli 2008 @ 22:50:
[...]

In sommige talen kan dat wel:

Je sais. ik gaf immers zelf ook al het php 'iets or die()' voorbeeld. Het door jou gequote stukje ging dan ook over Java.

Janoz wijzigde dit bericht 24-07-2008 08:33 (10%)