🚀 go-pugleaf

Dr.Ruud wrote:
> Toen ik John Bokma kietelde, kwam er dit uit:
> 
>>Dr.Ruud:
> 
> 
>>>Nog zo'n voorbeeld:
>>>
>>>     if ((sex == 'F') || ((sex == 'f') && (sex = 'F'))) do_female;
>>>     else if ((sex == 'M') || (sex = 'M')) do_male;
> 
> 
> Je had toch wel gezien dat het de bedoeling was dat deze code hetzelfde
> resultaat oplevert als die switch? (ik heb het niet getest)
> 
> 
> 
>>>Ik hou de literals overigens graag links van de '==', dus zo:
>>>
>>>     if (('F' == sex) || (('f' == sex) && (sex = 'F'))) do_female;
>>>     else if (('M' == sex) || (sex = 'M')) do_male;

Mijn bezwaar hiertegen is, dat het veel-te-veel tokens zijn.
Het *dwingt* de lezer om op de () te letten, zoals ook sommige
construkties de lezer in de *illusie* brengen dat whitespace/indentering
belangrijk is. Die belachelijke ('f' == gender) is *defensief*.

Het voordeel van de switch is, dat ie makkelijk is, omdat iedereen
hem onmiddelijk herkent. Bovendien *weet* iedereen dat er meer-dan 1 
cases kunnen zijn (itt if/else, waarbij er altijd precies twee opties 
zijn) Vandaar:
switch(gender) {
case 'm': gender = 'M';
case 'M': do_gozert();
   break;
case 'f': gender = 'F';
case 'F': do_wijffie();
   break;
default: do_teiltje("illegal gender: %x\n",  gender);
	}

Iedere "getrainde" lezer zal hier een switch herkennen, zich realiseren 
dat fall-tru mogelijk is, en (wellicht bij tweede lezing) constateren 
dat dat ook daadwerkelijk (hopelijk) goed gebruikt wordt.
IMHO kost de switch 2* zo weinig tijd *om te lezen* als de geneste 
if-construktie. De rest van de tijd kan besteed worden aan begrijpen,
wat 4* zo weinig tijd kost.



> Je bent dan vast e1n van de velen die de "==" en "!=" niet echt als
> symmetrische symbolen lezen. Ik zie veel liever een
> if (NULL != lange-en-complexe-expressie)
> dan andersom (en het liefst dus inclusief de onnodige "NULL !="),
> want je weet meteen waarmee vergeleken wordt.


Nee hoor. Ook hier kan je weer eea *weglaten*, waardoor de leesbaarheid
verhoogd wordt: die "NULL !=" kan worden vervangen door "".
Vergelijk:

while (NULL != (cp = fgets(fp, buff, sizeof buff))) {}

met:

while (cp = fgets(fp, buff, sizeof buff)) {}

Die laaste geeft tegenwoordig een "assignment used as truth value" 
warning, maar die cp-assignment is toch zinloos (binnen de {}, iig) :

while (fgets(fp, buff, sizeof buff)) {}

> 
> [ zieke humor snipped ]
> 
> Ik legde het op aan beginnende C-programmeurs, dat scheelde een hoop
> fouten en verdriet. Maar dan deden ze vervolgens natuurlijk zoiets:

Nee, dat is een illusie. je *kan* ze niks uitleggen.
Ze moeten zelf leren door hun neus te stoten. Leg ze de syntax uit, en
laat ze hun neus stoten.

>   unsigned int uiLen;
>   int i;
Variabelenamen om te HuiLen ....

>     :
>     :
>   for (i = 0; i++; i < uiLen) ...
> 
> en dan wilde dat soms niet stoppen.
>  

Dit zijn tikfouten (of denkfouten) die ze moeten
leren herkennen. Als denkfout gaat het vanzelf over
(of niet ...). Als tikfout istie lastig, omdat ie zeerzeerzeldzaam is.
Te zeldzaam om je ertegen te wapenen, IMHO. Hij komt zowiezo tot uiting
bij de 1e run, dus: geen probleem.


> 
> Liever niet zeg. Toch zijn "How *NOT* to do it" lijstjes erg leerzaam,
> nog veel meer als er een-verhaal-met-humor in de voorbeelden zit. En

Het probleem is, dat iedereen zijn eigen lijstjes moet ontwikkelen, 
omdat je die van een ander pas leert waarderen als ie overeenkomsten
vertoont met je eigen.
"Ervarend leren" heet dat ...

BTW leuk draadje, waar ging het over, eigenlijk ?

AvK