[alg] Slechtste programmeervoorbeelden deel 2

[EdwinG]

Dat niet iedereen even goed kan programmeren zal niemand verbazen. Sommigen maken het echter wel erg bond.
Een typisch voorbeeld van hoe het dus NIET moet:

Origineel: MSalters

code:

switch ( aBool )
{
    case TRUE:
        do_dit();
    case FALSE:
        do_dat();
    default:
        doe_iets_anders();
}

En hoe kan dat beter:

code:

if ( aBool ) {
  doe_dit();
}
doe_dat();
doe_iets_anders();

Vorig deel: [alg] slechtste prog voorbeelden

Heb je rare stukken code gevonden?
Ben je op beroerde database-layout gestuit?
Wist je niet dat het zo slecht kon?
Plaats het hier!

Om er nog wat van te kunnen leren:
Als je denkt dat de fout in de code niet voor zichzelf spreekt, probeer er dan bij te zetten wat er precies fout is, en hoe het beter/minder slecht had gekund. Dat jij de fout ziet, betekend niet dat iedereen het direct doorheeft.

Let op!
Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes.

Laatste wijziging: Code voorbeeldje aangepast. Blijkbaar was het slechte voorbeeld een prima bron voor discussies

[ Voor 27% gewijzigd door EdwinG op 30-10-2006 12:30 ]

[elTigro]

schoene schreef op vrijdag 27 oktober 2006 @ 11:21:
je kan het natuurlijk in een for-lusje steken

For is zwaar overrated

Ik heb overigens een keertje dit weten te bakken:

C++:

#include <iostream>
using namespace std;

int main () {
int c,i;
char kar;

c=1;
while (c=1) {
label:
kar=getchar ();
if ( int(kar) == 10 ) goto label;
for (i=0; i<kar; i++){
cout << "+"; }
printf (" > ");
continue;
}
exit (0);
}

Maar daar moet bij worden gezegd dat ik wel probeerde er een ranzig hoopje spagetti van te maken. (het werkt natuurlijk wel)
/edit: wel een for-lusje helaas

[ Voor 56% gewijzigd door elTigro op 27-10-2006 11:47 . Reden: for verhaal ]

[Gehakt]

Is het misschien een idee om er gelijk bij te zetten hoe het wel moet? Of iig de reden waarom iets gruwelijk fout is? Dan word het hele topic gelijk een stuk informatiever? Zeker bij ietwat ingewikkeldere stukken code waarvan beginners niet gelijk kunnen zien waarom het fout is bedoel ik dan.

[ Voor 26% gewijzigd door Gehakt op 27-10-2006 13:02 ]

[mulder]

EdwinG schreef op vrijdag 27 oktober 2006 @ 11:21:
...
Een typisch voorbeeld van hoe het dus NIET moet:

code:

switch ( aBool )
{
    case TRUE:
        do_dit();
    case FALSE:
        do_dat();
    default:
        doe_iets_anders();
}

...

Niks mis mee als het een Nullable bool is?

[Confusion]

Over 'een derde geslacht': http://en.wikipedia.org/wiki/ISO_5218. Ik geloof dat het op het grensvlak van privacywetgeving en non-discriminatie zelfs eigenlijk verplicht is het 'niet gespecificeerd' als geslacht aan te bieden als je persoonsgegevens opslaat. Er zijn wat medische condities die daar aanleiding toe geven.

[EdwinG]

Confusion schreef op vrijdag 27 oktober 2006 @ 13:12:
Over 'een derde geslacht': http://en.wikipedia.org/wiki/ISO_5218. Ik geloof dat het op het grensvlak van privacywetgeving en non-discriminatie zelfs eigenlijk verplicht is het 'niet gespecificeerd' als geslacht aan te bieden als je persoonsgegevens opslaat. Er zijn wat medische condities die daar aanleiding toe geven.

Ter verduideling, het ging om de volgende regel (vorig deel):

code:

`GESLACHT_ID` int(11) NOT NULL default '0',

'Niet gespecificeerd' is overigens niet de enige reden. GESLACHT_ID verwees hier naar een tabel waar per taal te naam van beide geslachten stond.

code:

ID   TAAL_ID   NAAM
1     1        Man
2     1        Vrouw
3     2        Man
4     2        Woman

Maar int(11) (het ging om mysql), gaat (ruim) van -2.000.000.000 tot + 2.000.000.000
Maar hoeveel talen zijn er eigenlijk? En met hoeveel kom je als bedrijf in aanraking?
Zelfs als je dat x3 doet zal je niet boven de 255 uitkomen.
(TAAL_ID was overigens ook een int(11))
In beide gevallen had een unsigned tinyint ruim voldaan.

[EdwinG]

Gehakt schreef op vrijdag 27 oktober 2006 @ 13:01:
Is het misschien een idee om er gelijk bij te zetten hoe het wel moet? Of iig de reden waarom iets gruwelijk fout is? Dan word het hele topic gelijk een stuk informatiever? Zeker bij ietwat ingewikkeldere stukken code waarvan beginners niet gelijk kunnen zien waarom het fout is bedoel ik dan.

Goed punt, ik zal daarover iets toevoegen aan de startpost.

[schoene]

elTigro schreef op vrijdag 27 oktober 2006 @ 11:40:

Ik heb overigens een keertje dit weten te bakken:

C++:

#include <iostream>
using namespace std;

int main () {
int c,i;
char kar;

c=1;
while (c=1) {
label:
kar=getchar ();
if ( int(kar) == 10 ) goto label;
for (i=0; i<kar; i++){
cout << "+"; }
printf (" > ");
continue;
}
exit (0);
}

Maar daar moet bij worden gezegd dat ik wel probeerde er een ranzig hoopje spagetti van te maken. (het werkt natuurlijk wel)
/edit: wel een for-lusje helaas

ik wil zelfs niet weten wat de bedoeling was

[MTWZZ]

^^ iets met plusjes

[Anoniem: 155221]

of deze:

Visual Basic:

Private Sub Command1_Click()
maakLeeg
End Sub

oke niks mis mee, maar nou bevat maakLeeg

Visual Basic:

Private Sub maakLeeg()
txtVeld(1).Text = ""
txtVeld(2).Text = ""
txtVeld(3).Text = ""
...
...
txtVeld(100).Text = ""
End Sub

het werd gebruik om een soort tabel van 100 tekstvelden te legen
het werkt wel, maar het kan natuurlijk makkelijker

[schoene]

Anoniem: 155221 schreef op vrijdag 27 oktober 2006 @ 14:48:

het werd gebruik om een soort tabel van 100 tekstvelden te legen
het werkt wel, maar het kan natuurlijk makkelijker

vergeet niet: we zijn tegen for-lusjes

[Anoniem: 155221]

2 jaar geleden moesten we een methode schrijven dat een of andere berekening moest uitvoeren.
we begonnen gezamelijk en na 2 minuten stond iemand op en zei dat ie al klaar was.
hij had 6 regels code opgeschreven, waar je normaal iets van 40regels voor nodig had.
bleek dat hij gewoon ingetyped had wat de computer moest doen in nederlandse taal

zelf had ik de code niet gezien, maar hieronder vind je een stukje als voorbeeld waar je aan zou kunnen denken

code:

zoek in database op dubbele waarden
verwijder dubbele gegevens, en sorteer op leeftijd
sla de gevonden gegevens op in c:\waarde.txt
sluit programma

[Michali]

Dat is een hele goede methode om een methode te schrijven .

Wordt ook in code complete uitgelegd onder de naam Pseudocode Programming Process (PPP). Eerst schrijf je dan puur in normale taal op wat er moet gebeuren stap voor stap. Dan maak je van die regels commentaar, waarna je na iedere regel commentaar in code gaat uitschrijven hoe het gerealiseerd wordt. Werkt snel en je hebt gelijk goed bruikbaar commentaar.

[P_de_B]

Confusion schreef op vrijdag 27 oktober 2006 @ 13:12:
Over 'een derde geslacht': http://en.wikipedia.org/wiki/ISO_5218. Ik geloof dat het op het grensvlak van privacywetgeving en non-discriminatie zelfs eigenlijk verplicht is het 'niet gespecificeerd' als geslacht aan te bieden als je persoonsgegevens opslaat. Er zijn wat medische condities die daar aanleiding toe geven.

Dan zou het gewoon een NULLable veld moeten zijn, immers NULL staat voor 'onbekend' of 'niet gespecificeerd'

[Viper®]

Michali schreef op vrijdag 27 oktober 2006 @ 15:21:
Dat is een hele goede methode om een methode te schrijven .

Wordt ook in code complete uitgelegd onder de naam Pseudocode Programming Process (PPP). Eerst schrijf je dan puur in normale taal op wat er moet gebeuren stap voor stap. Dan maak je van die regels commentaar, waarna je na iedere regel commentaar in code gaat uitschrijven hoe het gerealiseerd wordt. Werkt snel en je hebt gelijk goed bruikbaar commentaar.

Jammer nou dat het omzetten van 'deze' taal naar code functionaliteit het grootste werk is en het 'echte' developers werk.

[P_de_B]

Viper® schreef op vrijdag 27 oktober 2006 @ 15:24:
[...]


Jammer nou dat het omzetten van 'deze' taal naar code functionaliteit het grootste werk is en het 'echte' developers werk.

Hmm, is dat eigenlijk wel zo? Ik vind het minstens zo belangrijk dat men onder woorden kan brengen wat een stukje code moet doen, hoe een algoritme het beste kan werken. Dat goed kunnen maakt je imho een goede developer. Het stukje code inkloppen kan iedereen dan wel bij wijze van spreken.

[Viper®]

P_de_B schreef op vrijdag 27 oktober 2006 @ 15:25:
[...]

Hmm, is dat eigenlijk wel zo? Ik vind het minstens zo belangrijk dat men onder woorden kan brengen wat een stukje code moet doen, hoe een algoritme het beste kan werken. Dat goed kunnen maakt je imho een goede developer. Het stukje code inkloppen kan iedereen dan wel bij wijze van spreken.

Het denkproces wat jij nu omschrijft heb ik ondergebracht bij het developen.

In het voorbeeld was de omschrijving al gegevens, dit was dus puur overtypen, easy. Vervolgens ga je als ontwikkelaar/architect kijken hoe je dit het beste/efficientste (afhankelijk van rfp etc) kan bewerkstelliggen. hier zit een deel architect ontwerp en inzicht bij.

programmeren is dus zeker niet het domweg kunnen proppen van code


we denken dus aan hetzelfde, alleen we zeiden het adners

[prototype]

EdwinG schreef op vrijdag 27 oktober 2006 @ 11:21:
Dat niet iedereen even goed kan programmeren zal niemand verbazen. Sommigen maken het echter wel erg bond.
Een typisch voorbeeld van hoe het dus NIET moet:

code:

switch ( aBool )
{
    case TRUE:
        do_dit();
    case FALSE:
        do_dat();
    default:
        doe_iets_anders();
}

En hoe kan dat beter:

code:

if ( aBool ) {
  doe_dit();
}
else {
  doe_dat();
}

Vorig deel: [alg] slechtste prog voorbeelden

Zoals Don Facundo al zei, kan deze opstelling wel wanneer je met nullable types kan werken zoals dat het geval is bij C#.

C#:

            bool? b = null; //nullable bool declaratie en assignment

            switch (b)
            {
                case true:
                case false:
                    Console.WriteLine(b);
                    break;
                default:
                    Console.WriteLine("Default");
                    break;
            }

De default case wordt nu bereikt omdat b null is.

[edit]
On a side note, volgens mij krijg je een relatief gigantische geheugen overhead erbij indien je met nullable primitive types werkt, omdat deze primitive volgens mij gewoon gewrapped wordt in de generic Nullable, die in size naar alle waarschijnlijkheid veel groter is dan de boolean die in theorie slechts 1 bit zou moeten beslaan; in de praktijk is het wat groter met diverse overheads nog erbij, maar een object is toch altijd groter me dunkt. Om deze reden zou ik het dan ook even iets kritischer bekijken.

[ Voor 18% gewijzigd door prototype op 27-10-2006 15:50 ]

[.oisyn]

of als de bool een tristate is.

[Tomatoman]

EdwinG schreef op vrijdag 27 oktober 2006 @ 13:25:
[...]


Ter verduideling, het ging om de volgende regel (vorig deel):

[...]


'Niet gespecificeerd' is overigens niet de enige reden. GESLACHT_ID verwees hier naar een tabel waar per taal te naam van beide geslachten stond.

code:

ID   TAAL_ID   NAAM
1     1        Man
2     1        Vrouw
3     2        Man
4     2        Woman

Maar int(11) (het ging om mysql), gaat (ruim) van -2.000.000.000 tot + 2.000.000.000
Maar hoeveel talen zijn er eigenlijk? En met hoeveel kom je als bedrijf in aanraking?
Zelfs als je dat x3 doet zal je niet boven de 255 uitkomen.
(TAAL_ID was overigens ook een int(11))
In beide gevallen had een unsigned tinyint ruim voldaan.

Een kennis die veel onderzoeken deed in de medische sector vertelde me dat zij in databases vaak 5 verschillende geslachten tegenkwam:
• man
• vrouw
• man, voorheeen vrouw
• vrouw, voorheen man
• onbekend

De categorie 'onbekend' is noodzakelijk voor het geval het geslacht niet werd ingevuld in een enquête of niet uit andere gegevens te herleiden was. De twee omgebouwde geslachten zijn met name in de medische wereld relevant, maar ik kan me voorstellen dat ze bijvoorbeeld ook van belang zijn voor de burgerlijke stand. In een orderverwerkend systeem lijkt het me echter niet zo belangrijk om te weten dat een vrouw die een cd bestelt vroeger een man was . Niettemin: de categorie onbekend heb je soms gewoon nodig om te voorkomen dat er maar wat gegokt wordt.

[.oisyn]

Niettemin: de categorie onbekend heb je soms gewoon nodig om te voorkomen dat er maar wat gegokt wordt

En daar heb je dus de NULL waarde voor in een database.

[ Voor 50% gewijzigd door .oisyn op 27-10-2006 15:58 ]

[Tanuki]

PHP:

  function CheckExistence($item,$gebruikers_items) {
    for ($i=0; $i< count($gebruikers_items); $i++) {
      if ($gebruikers_items[$i] == $item) {
        return true;
        break;
      }
    }
    return false;
  }

A.K.A. in_array

En waar dient die break; voor?

[ Voor 6% gewijzigd door Tanuki op 27-10-2006 16:07 ]

[Viper®]

.oisyn schreef op vrijdag 27 oktober 2006 @ 15:57:
[...]

En daar heb je dus de NULL waarde voor in een database.

Niet alle databases ondersteun(d)en null values

[Dido]

Viper® schreef op vrijdag 27 oktober 2006 @ 16:18:
Niet alle databases ondersteun(d)en null values

Die (d) mag je gevoeglijk weglaten, er zijn DB's die het nog steeds niet doen, helaas

[Robtimus]

schoene schreef op vrijdag 27 oktober 2006 @ 14:54:
[...]
vergeet niet: we zijn tegen for-lusjes

Visual Basic:

Dim i As Integer

i = 1
Do While (i <= 100)
    txtVeld(i).Text = ""
    i = i + 1
Loop

Wat nou for-lusje?

l0c4lh0st schreef op vrijdag 27 oktober 2006 @ 16:07:
En waar dient die break; voor?

Geen idee, maar in Java geeft dit een compiler error vanwege een "unreachable statement".

[RobIII]

Anoniem: 155221 schreef op vrijdag 27 oktober 2006 @ 14:48:
of deze:

Visual Basic:

Private Sub Command1_Click()
maakLeeg
End Sub

oke niks mis mee, maar nou bevat maakLeeg

Visual Basic:

Private Sub maakLeeg()
txtVeld(1).Text = ""
txtVeld(2).Text = ""
txtVeld(3).Text = ""
...
...
txtVeld(100).Text = ""
End Sub

het werd gebruik om een soort tabel van 100 tekstvelden te legen
het werkt wel, maar het kan natuurlijk makkelijker

Een beetje compiler omptimaliseerd dat toch?

[Tomatoman]

.oisyn schreef op vrijdag 27 oktober 2006 @ 15:57:
[...]

En daar heb je dus de NULL waarde voor in een database.

Of je nu NULL gebruikt of een andere ID-waarde is maar net wat je voorkeur heeft. Zonder kennis hoe je geslachts-ID's moet interpreteren kun je sowieso niets met de data. Het gaat erom dat in een waarde voor 'onbekend geslacht' is voorzien.

[edit]
Uit stylistisch oogpunt vind ik trouwens dat 0 voor 'vrouw' moet staan en 1 voor 'man'

[ Voor 11% gewijzigd door Tomatoman op 27-10-2006 16:44 ]

[Janoz]

RobIII schreef op vrijdag 27 oktober 2006 @ 16:36:
[...]

Een beetje compiler omptimaliseerd dat toch?

Klopt, een beetje compiler unrolled die loop. Beetje prematuur dat de developer het al gedaan heeft

[P_de_B]

tomatoman schreef op vrijdag 27 oktober 2006 @ 16:40:
[...]
Of je nu NULL gebruikt of een andere ID-waarde is maar net wat je voorkeur heeft. Zonder kennis hoe je geslachts-ID's moet interpreteren kun je sowieso niets met de data. Het gaat erom dat in een waarde voor 'onbekend geslacht' voorziet.

Mwoah, NULLs zijn daar voor, gebruik die dan ook in plaats van een eigen gekozen waarde voor 'onbekend'

[Tanuki]

Oké, wat is er nou precies tegen for-lussen? Ik snap niet wat er zo erg aan kan zijn? Je kunt ook wel een while maken, maar als je een simpel tellertje wil hebben is een for-lus veel makkelijker.

[Tomatoman]

P_de_B schreef op vrijdag 27 oktober 2006 @ 16:43:
[...]

Mwoah, NULLs zijn daar voor, gebruik die dan ook in plaats van een eigen gekozen waarde voor 'onbekend'

Jij wilt het dus zo:

code:

ID       Betekenis
------   -------
<NULL>   onbekend
0        man
1        vrouw
2        man, voorheeen vrouw
3        vrouw, voorheen man

Wat is hier het voordeel om een NULL-waarde te gebruiken? Het maakt query's ingewikkelder, het maakt tabellen lastiger te interpreteren en het is niet logisch.

Waarom zou NULL trouwens staan voor onbekend? Ik vind het een beetje onzin om een NULL-waarde te gebruiken voor 'onbekend'. Het is een arbitraire keuze en er is geen enkele reden waarom je de NULL-waarde niet net zo goed kunt gebruiken voor bijvoorbeeld 'man, voorheen vrouw'. Een NULL-waarde gebruik je soms voor een bijzondere situatie en 'man, voorheen vrouw' vind ik toch echt een stuk bijzonderder dan een onbekend geslacht.

[.oisyn]

Het is wel logisch, Null betekent namelijk precies "ongedefinieerd". Alle SQL comparisons zijn daar ook op gebouwd (true OR NULL is bijvoorbeeld true, terwijl false OR NULL juist NULL oplevert)

[ Voor 47% gewijzigd door .oisyn op 27-10-2006 17:03 ]

[P_de_B]

Nee, zo niet natuurlijk, NULL is niet een soort primary key van een lookup tabel.

code:

Tabel Personen

Naam: Peter
Leetijd: 30
Geslacht: NULL

Waarom zou NULL trouwens staan voor onbekend?

Waarom zijn de bananen krom? Het is gewoon zo. NULL is onbekend. Als iemand het geslacht niet invuld is het NULL.

.oisyn schreef op vrijdag 27 oktober 2006 @ 17:02:
Het is wel logisch, Null betekent namelijk precies "ongedefinieerd". Alle SQL comparisons zijn daar ook op gebouwd (true OR NULL is bijvoorbeeld true, terwijl false OR NULL juist NULL oplevert)

En NULL != NULL

[ Voor 32% gewijzigd door P_de_B op 27-10-2006 17:05 ]

[.oisyn]

P_de_B schreef op vrijdag 27 oktober 2006 @ 17:03:
En NULL != NULL

Dit klopt niet, hier komt NULL uit, geen true (als ze beide ongedefinieerd zijn weet je immers ook niet of ze gelijk of ongelijk zijn - dat is immers ook ongedefinieerd, en dus NULL)

[P_de_B]

.oisyn schreef op vrijdag 27 oktober 2006 @ 17:07:
[...]

Dit klopt niet, hier komt NULL uit, geen true (als ze beide ongedefinieerd zijn weet je immers ook niet of ze gelijk of ongelijk zijn - dat is immers ook ongedefinieerd, en dus NULL)

Inderdaad is de uitkomst niet 'FALSE', wat ik bedoelde aan te geven is dat NULL nooit gelijk kan zijn aan NULL.

[WormLord]

Dido schreef op vrijdag 27 oktober 2006 @ 16:21:
[...]

Die (d) mag je gevoeglijk weglaten, er zijn DB's die het nog steeds niet doen, helaas

Nog veel erger is het dat er zogenaamde database experts zijn die null-waardes vies vinden en liever een waarde kiezen die dan maar 'onbekend' betekend. En dan in de eventuele stamtabel maar een 'ondekend'-record toevoegen

[JeRa]

l0c4lh0st schreef op vrijdag 27 oktober 2006 @ 16:57:
Oké, wat is er nou precies tegen for-lussen? Ik snap niet wat er zo erg aan kan zijn? Je kunt ook wel een while maken, maar als je een simpel tellertje wil hebben is een for-lus veel makkelijker.

Dit zou ik ook willen weten

[mulder]

WormLord schreef op vrijdag 27 oktober 2006 @ 18:01:
[...]

Nog veel erger is het dat er zogenaamde database experts zijn die null-waardes vies vinden en liever een waarde kiezen die dan maar 'onbekend' betekend. En dan in de eventuele stamtabel maar een 'ondekend'-record toevoegen

Ja anders doe je dat runtime? Het is helemaal niet een rare optie om zo'n record te gebruiken, het kan gewoon een default waarde zijn.

[.oisyn]

P_de_B schreef op vrijdag 27 oktober 2006 @ 17:10:
[...]

Inderdaad is de uitkomst niet 'FALSE', wat ik bedoelde aan te geven is dat NULL nooit gelijk kan zijn aan NULL.

Warning: dit is een nitpicking post

Ze zijn gelijk idd, maar dus ook niet ongelijk, terwijl dat toch is wat je zegt

Als jij zegt dat geldt dat a == b, dan vat ik dat op als dat uit die expressie true komt. Uit NULL != NULL komt geen true, maar ook niet false. Je kunt imho dus niet zeggen dat NULL != NULL

[elTigro]

schoene schreef op vrijdag 27 oktober 2006 @ 14:54:
[...]


vergeet niet: we zijn tegen for-lusjes

dank u!

JeRa schreef op vrijdag 27 oktober 2006 @ 18:07:
[...]

Dit zou ik ook willen weten

ik ook

[ Voor 31% gewijzigd door elTigro op 27-10-2006 18:27 ]

[Anoniem: 27195]

tomatoman schreef op vrijdag 27 oktober 2006 @ 15:53:
Een kennis die veel onderzoeken deed in de medische sector vertelde me dat zij in databases vaak 5 verschillende geslachten tegenkwam:
• man
• vrouw
• man, voorheeen vrouw
• vrouw, voorheen man
• onbekend

En dan heb je eig ook nog zoiets als Intersexuality

[Confusion]

P_de_B schreef op vrijdag 27 oktober 2006 @ 15:22:
Dan zou het gewoon een NULLable veld moeten zijn, immers NULL staat voor 'onbekend' of 'niet gespecificeerd'

De ISO standaard definieert vier waarden, omdat er een verschil is tussen 'onbekend' en 'niet gespecificeerd'. Het kan zijn dat iemand zijn geslacht niet kan of wil mededelen. Dat is een andere situatie dan wanneer het geslacht niet bekend is, bijvoorbeeld als je alleen mensen van wie het nog niet bekend is wilt vragen hun geslacht te specificeren. Dan wil je mensen die het al een keer hebben ingevuld niet lastig vallen.

[Anoniem: 14829]

l0c4lh0st schreef op vrijdag 27 oktober 2006 @ 16:07:

PHP:

  function CheckExistence($item,$gebruikers_items) {
    for ($i=0; $i< count($gebruikers_items); $i++) {
      if ($gebruikers_items[$i] == $item) {
        return true;
        break;
      }
    }
    return false;
  }

A.K.A. in_array

En waar dient die break; voor?

Ik betrap me daar (een break na een return) zelf ook vaak op als ik in C# bezig ben. Heb namelijk jaren lang, en nu nog steeds, vooral ontwikkeld in Delphi/Pascal, en die heeft geen 'return' statement. Binnen een functie set je dan de Result variabele (of de variabele met de naam van de functie), en die wordt aan het eind van de functie (of bij vroegtijdig exitten) als resultaat geretourneerd. Een break is in zo'n geval gewoon noodzakelijk.

Idem met 'in_array'. Een goede programmeur (in een andere taal) die zich aardig kan redden in PHP zal vaak niet alle PHP ins en outs kennen, maar komt wel tot degelijke en goedwerkende oplossingen, zoals jouw voorbeeld.

M.i. dus helemaal niet zo'n slecht programmeervoorbeeld.

[Grijze Vos]

Anoniem: 14829 schreef op vrijdag 27 oktober 2006 @ 20:11:
[...]

M.i. dus helemaal niet zo'n slecht programmeervoorbeeld.

Mijn docenten hun tenen zouden krommen als ze dat zouden lezen.
While loop met een goede guard, zo "hoor" je dat te doen. (Als academicus dan.)

[Robtimus]

Nou dan weet je vast dat een for altijd perfect om te zetten is in een while.

code:

for (init; guard, increment) {
    code
}

wordt gewoon

code:

init;
while (guard) {
    code;
    increment;
}

Een for heeft daarbij zelfs vaak een voordeel: het wordt altijd uitgevoerd, zelfs als je een continue uitvoert. Alleen met een break of return omzeil je hem.

Maarja, docenten zijn dan ook faliekant tegen continue, break en return midden in code.

[Michali]

Viper® schreef op vrijdag 27 oktober 2006 @ 15:24:
[...]


Jammer nou dat het omzetten van 'deze' taal naar code functionaliteit het grootste werk is en het 'echte' developers werk.

Als het op een goede manier uitvoert, dan is het juist niet zo veel werk. Dan heb ik je al uitgeschreven hoe je het probleem gaat oplossen en dan is het schrijven de code een vrij eenvoudige taak. Het ontwerpen van een architectuur gaat op deze manier natuurlijk niet. Maar dat behoort ook niet tot het schrijven van een methode. Dat is hoe het wordt gedaan en niet direct wat.

Verder moet je niet direct kijken naar hoe je iets op de efficientste manier gaat oplossen. Beter is om eerst voor de meest logische en gestructureerde oplossing (met performance natuurlijk wel in het achterhoofd) te gaan, en later je applicatie profilen om performance bottlenecks te vinden. Het schijnt (zoals met zo veel zaken) dat 80% van de tijd in 20% van je code gaat zitten. Om dan overal rekening met performance te gaan houden is zonde van je tijd.

[prototype]

IceManX schreef op vrijdag 27 oktober 2006 @ 20:57:
Nou dan weet je vast dat een for altijd perfect om te zetten is in een while.

code:

for (init; guard, increment) {
    code
}

wordt gewoon

code:

init;
while (guard) {
    code;
    increment;
}

Een for heeft daarbij zelfs vaak een voordeel: het wordt altijd uitgevoerd, zelfs als je een continue uitvoert. Alleen met een break of return omzeil je hem.

Maarja, docenten zijn dan ook faliekant tegen continue, break en return midden in code.

Mjah, het is niet geheel equivalent Bij de init in de forloop wordt er gebruik gemaakt van een lokale scope gebonden aan de for+compoundstatement. Bij de while declareer je je init buiten de compound van de while en zal die ook nog aanwezig zijn na de while loop.
En ja, mijn docenten zijn ook zeer tegen de flow van code aanpassen mbv continue's, breaks en returns midden in code, maar dat komt volgens mij voornamelijk vanwege het feit dat er met loopinvariants gewerkt dient te worden en die returns evt een belemmering zouden kunnen vormen in het goed formuleren ervan (zelf geen last van maar goed).

[Robtimus]

prototype schreef op vrijdag 27 oktober 2006 @ 21:34:
Mjah, het is niet geheel equivalent Bij de init in de forloop wordt er gebruik gemaakt van een lokale scope gebonden aan de for+compoundstatement. Bij de while declareer je je init buiten de compound van de while en zal die ook nog aanwezig zijn na de while loop.

Klopt, nog een reden dat ik juist wel fan ben van for loops. Geen "int i" en "int j" die door de rest van het blok (vaak method) door bruikbaar zijn zonder dat je ze nog gebruikt. Heerlijk die for-local variabelen, in C mis ik dat nog wel een beetje.

En ja, mijn docenten zijn ook zeer tegen de flow van code aanpassen mbv continue's, breaks en returns midden in code, maar dat komt volgens mij voornamelijk vanwege het feit dat er met loopinvariants gewerkt dient te worden en die returns evt een belemmering zouden kunnen vormen in het goed formuleren ervan (zelf geen last van maar goed).

Ah ja, de loop invariant. Hoe je een kwartier bezig bent om te bewijzen dat je stuk code dat je binnen 5 minuten schrijft correct is.

* Robtimus heeft Technische Informatica aan de TU/e gedaan - les gehad van de Dijkstal fanatici wijlen Van Gasteren, Hoogerwoord en Feijen.

Ooit nog eens een korte discussie met die laatste gehad. Ik was bezig met een voorbeeldopgave, had een goed stuk code verzonnen maar miste een stuk van de afleiding. Volgens Feijen kon het dus nooit correct zijn terwijl ik gewoon 100% zeker wist dat het dat wel was. Ik heb er maar geen moeite voor gedaan, die laatste twee waren zo flexibel als een baksteen.

[Anoniem: 14829]

IceManX schreef op vrijdag 27 oktober 2006 @ 20:57:
Maarja, docenten zijn dan ook faliekant tegen continue, break en return midden in code.

Tja, die docenten hebben waarschijnlijk ook nog nooit software moeten afleveren dat doet wat 't moet doen, afgeleverd binnen de gestelde deadline, en dan ook nog 's performt zoals de bedoeling was.

[Macros]

Als je die scope van de loop variabele beperkt wil houden tot de loop kan een de forloop toch herschrijven naar deze 100% equivalente code:

code:

{
   init;
   while (guard) {
      code;
      increment;
   }
}

[ Voor 19% gewijzigd door Macros op 28-10-2006 01:27 ]

[Paul C]

Ik snap nog niet helemaal wat er bezwaarlijk is aan een for-loop. Ik begrijp dat een for-loop dubbel op is in de zin dat je het met een while-loop ook heel goed kunt oplossen en kan me zelfs voorstellen dat het voor sommige mensen in het begin onlogisch wat wanneer te gebruiken, maar IMHO maakt het je code duidelijker als je beetje coden kan. Bij correct gebruik van een for-loop weet je zeker dat het gaat om een geval waar code-x y keer wordt uitgevoerd. Heel duidelijk, terwijl je bij een while-loop allerlei voorwaarden kunt hebben. Als je dus code bekijkt en je ziet een for-loop, dan weet je gewoon dat er y iteraties van code-x wordt uitgevoerd terwijl en bij een while-loop iets complexers aan de hand is. Prima scheiding IMHO.

Als we for moeten vervangen door while, waarom vervangen we dan de if dan niet ook door while, dat kan ook?

[Mastermind]

IceManX schreef op vrijdag 27 oktober 2006 @ 16:28:
[...]

Visual Basic:

Dim i As Integer

i = 1
Do While (i <= 100)
    txtVeld(i).Text = ""
    i = i + 1
Loop

Wat nou for-lusje?

Het niet niet gebruikelijk Textboxen in een array te zetten. Met name omdat je in de designer de textboxen op het veld sleept en deze automatisch een instantie krijgen.
Beter is de textboxen op een Panel genaamd panel1 te slepen en:

C#:

foreach (Control c in panel1.Controls) if (c is TextBox) c.Text = "";

[schoene]

pcmadman schreef op zaterdag 28 oktober 2006 @ 01:46:
Ik snap nog niet helemaal wat er bezwaarlijk is aan een for-loop.

Toch maar eventjes verduidelijken dat ik denk dat niemand tegen een for-loop is. Vreemd dat zelf zo iets serieus kan opgenomen worden

[mulder]

Mastermind schreef op zaterdag 28 oktober 2006 @ 05:21:
[...]

Het niet niet gebruikelijk Textboxen in een array te zetten. Met name omdat je in de designer de textboxen op het veld sleept en deze automatisch een instantie krijgen.
Beter is de textboxen op een Panel genaamd panel1 te slepen en:

C#:

foreach (Control c in panel1.Controls) if (c is TextBox) c.Text = "";

In Visual Studio.Net + VB.Net, niet in Visual Basic.

[P_de_B]

.oisyn schreef op vrijdag 27 oktober 2006 @ 18:15:
[...]

Warning: dit is een nitpicking post

Ze zijn gelijk idd, maar dus ook niet ongelijk, terwijl dat toch is wat je zegt

Als jij zegt dat geldt dat a == b, dan vat ik dat op als dat uit die expressie true komt. Uit NULL != NULL komt geen true, maar ook niet false. Je kunt imho dus niet zeggen dat NULL != NULL

Pfff miereneuker
.
Maar je hebt gelijk. Ik bedoel hetzelfde maar druk me inderdaad niet goed uit

[Paul C]

schoene schreef op zaterdag 28 oktober 2006 @ 09:49:
[...]


Toch maar eventjes verduidelijken dat ik denk dat niemand tegen een for-loop is. Vreemd dat zelf zo iets serieus kan opgenomen worden

Dat dacht ik ook, maar begon er langzaam aan te twijfelen

[prototype]

IceManX schreef op vrijdag 27 oktober 2006 @ 22:02:
Ah ja, de loop invariant. Hoe je een kwartier bezig bent om te bewijzen dat je stuk code dat je binnen 5 minuten schrijft correct is.

* prototype heeft Technische Informatica aan de TU/e gedaan - les gehad van de Dijkstal fanatici wijlen Van Gasteren, Hoogerwoord en Feijen.

Ooit nog eens een korte discussie met die laatste gehad. Ik was bezig met een voorbeeldopgave, had een goed stuk code verzonnen maar miste een stuk van de afleiding. Volgens Feijen kon het dus nooit correct zijn terwijl ik gewoon 100% zeker wist dat het dat wel was. Ik heb er maar geen moeite voor gedaan, die laatste twee waren zo flexibel als een baksteen.

Mjah, het is wel heel stoer natuurlijk dat je het kan schrijven , maar ik zie het nut er na 2 jaar nog steeds niet van in, i.e. in de praktijk gebruik ik het zelden. Daarbij is het bewijs c.q. de invariant vaak zo kryptisch geformuleerd dat het meer tijd kost om de invariant te begrijpen dan de lus zoals hij er staat. Maar goed, gelukkig hebben we die programmeervakken dan ook al lang in het verleden goed afgesloten en hoeven we er alleen nog maar uit nostalgische overwegingen naar terug te kijken

[.oisyn]

Macros schreef op zaterdag 28 oktober 2006 @ 01:27:
Als je die scope van de loop variabele beperkt wil houden tot de loop kan een de forloop toch herschrijven naar deze 100% equivalente code:

code:

{
   init;
   while (guard) {
      code;
      increment;
   }
}

Dus niet 100% equivalent. Want wat nou als er in de code een continue staat? Of wil je dan een goto suggereren?

Dit zou wel equivalent zijn, maar echt mooier wordt het er niet op

code:

{
    init;
    bool doIncrement = false;
    while (true)
    {
        if (doIncrement)
            increment;
        if (!guard)
            break;
        doIncrement = true;
        code;
    }
}

Raad nu eens waarom de for-lus is uitgevonden.

[ Voor 27% gewijzigd door .oisyn op 28-10-2006 15:34 ]

[Gilles de Geus]

.oisyn schreef op zaterdag 28 oktober 2006 @ 15:29:
Dit zou wel equivalent zijn, maar echt mooier wordt het er niet op

code:

{
    init;
    bool doIncrement = false;
    while (true)
    {
        if (doIncrement)
            increment;
        if (!guard)
            break;
        doIncrement = true;
        code;
    }
}

Raad nu eens waarom de for-lus is uitgevonden.

Ik weet niet in welke taal je programmeert maar in C++ is een for increment pas na de loop, vlak voor de her evaluatie van de guard...

Maar gelukkig hangt het ook van de compiler af wat de scope van je variabele is, da's pas echt briljant

[ Voor 7% gewijzigd door Gilles de Geus op 28-10-2006 17:29 ]

[Grijze Vos]

IceManX schreef op vrijdag 27 oktober 2006 @ 22:02:
Ooit nog eens een korte discussie met die laatste gehad. Ik was bezig met een voorbeeldopgave, had een goed stuk code verzonnen maar miste een stuk van de afleiding. Volgens Feijen kon het dus nooit correct zijn terwijl ik gewoon 100% zeker wist dat het dat wel was. Ik heb er maar geen moeite voor gedaan, die laatste twee waren zo flexibel als een baksteen.

Heh, Feijen is een beetje zo in de trant van "oh, som 1 is goed, som 2 is goed, wat, dat is een domme fout bij som 3, laat ik 2 ook fout tellen zodat je een 4 krijgt."

[edit]
Even voor de duidelijkheid, ik heb helemaal niks tegen een for loop hoor, maar sommige mensen kunnen het wel zwaar overusen:

C:

for ( eof = 0, skip = 0; ; ) {
...
}

Sorry, maar een while loop is daar gewoon veel duidelijker.

[ Voor 16% gewijzigd door Grijze Vos op 28-10-2006 19:27 ]

[Robtimus]

Mee eens. Een for loop moet een guard hebben, en of een initializer of een increment. Dat die laatste niet altijd nodig is blijkt wel uit de pre Java5 manier van Iterators gebruiken:

Java:

for (Iterator i = someCollection.iterator(); i.hasNext(); ) {
    Object o = i.next();
    // code
}

[prototype]

IceManX schreef op zaterdag 28 oktober 2006 @ 19:55:
Mee eens. Een for loop moet een guard hebben, en of een initializer of een increment. Dat die laatste niet altijd nodig is blijkt wel uit de pre Java5 manier van Iterators gebruiken:

Java:

for (Iterator i = someCollection.iterator(); i.hasNext(); ) {
    Object o = i.next();
    // code
}

Nahjah, wat dacht je dan van het gegeven dus dat als je midden in je code breaked dat het dan fout is. Stel de volgende situatie voor, wat bij mij dus 2 jaar geleden bij het practicum speelde:

Java:

for(Object o : eenbepaaldecollectie)
{
    if (o == foobar)
        //ik wil hieruit breken.
}

Toen ik dit voorlegde bij de studentassistent meende ik dat deze zei dat ik het maar moest herschrijven dan, b.v. naar:

Java:

for(Iterator it = eenbepaaldecollectie.iterator(); guard && it.hasNext(); )
{
    o = it.next();
    if (o == foobar)
        guard = false;
}

Bij dat laatste is het wel handig nu dat je op de guard kan controleren na de lus (indien je deze dus buiten de for declareert), maar dat had bij het eerste ook eenvoudig gekund... maar goed, als het niet volgens de format is... zeer waarschijnlijk dan dat het foutgerekend wordt. Ik had iig geen zin meer om erover in discussie te gaan, afgetekend is afgetekend is het op een gegeven moment

Java:

boolean guard = true;
for(Object o : eenbepaaldecollectie)
{
    if (o == foobar)
    {
        guard = false;
        break;
    }
}

[.oisyn]

Gilles de Geus schreef op zaterdag 28 oktober 2006 @ 17:28:
[...]

Ik weet niet in welke taal je programmeert maar in C++ is een for increment pas na de loop, vlak voor de her evaluatie van de guard...

Precies zoals ik mijn code opschreef dus, kijk nog maar eens goed .

Maar gelukkig hangt het ook van de compiler af wat de scope van je variabele is, da's pas echt briljant

Nee, de C++ standaard zegt dat een variabele die binnen de haakjes van de for wordt gedefinieerd alleen binnen de scope van de for-lus leeft (3.3.2/4). Als er compilers zijn die zich daar niet aan houden dan is dat geen standaard C++, en waarschijnlijk zinspeel je hier op VC++ 6.0, die alweer 8 (!!!) jaar oud is, en waar met een #define for if (false) { } else for omheen te werken is.

[ Voor 12% gewijzigd door .oisyn op 29-10-2006 02:31 ]

[Anoniem: 42145]

Anoniem: 14829 schreef op zaterdag 28 oktober 2006 @ 00:27:
[...]
Tja, die docenten hebben waarschijnlijk ook nog nooit software moeten afleveren dat doet wat 't moet doen, afgeleverd binnen de gestelde deadline, en dan ook nog 's performt zoals de bedoeling was.

Denk het wel. In tegenstelling tot lagere- en middelbare school docenten, en volgens mij ook nog HBO docenten bestaat er niet zoiets als een fulltime WO docent. 'docenten' zijn altijd onderzoekers die slechts een gedeelte van hun tijd besteden aan lesgeven. Doet wat 't moet doen is zowat het allerbelangrijkste in wetenschappelijk software. Afleveren binnen een deadline is iets wat minder vaak een rol kan spelen. Soms heeft een onderzoeker schier oneindig de tijd voor een stuk code, maar in het geval van conferenties en natuurlijk in het geval van samenwerkingen met bedrijven is er wel zeer zeker een deadline.

Performance is in veel (niet alle) wetenschappelijk software helemaal een punt van grote aandacht. Men kan rustig een maand, misschien langer, nadenken over een optimalisatie waaraan in het bedrijfsleven nog niets een uur besteed mag worden.

[raoulduke]

EdwinG schreef op vrijdag 27 oktober 2006 @ 11:21:
Dat niet iedereen even goed kan programmeren zal niemand verbazen. Sommigen maken het echter wel erg bond.
Een typisch voorbeeld van hoe het dus NIET moet:

code:

switch ( aBool )
{
    case TRUE:
        do_dit();
    case FALSE:
        do_dat();
    default:
        doe_iets_anders();
}

En hoe kan dat beter:

code:

if ( aBool ) {
  doe_dit();
}
else {
  doe_dat();
}

Ik weet niet of de startpost grappig bedoeld was, maar volgens mij staat er een fout in. Misschien was de startpost zelf wel een voorbeeld van zo'n programmeerfoutje. De suggestie voor verbetering die gegeven wordt is namelijk niet gelijk aan het origineel.

De flow van beide stukjes is namelijk (bij gewone booleans, dus geen nullables of tristates):

Origineel, TRUE: do_dit, do_dat, do_iets_anders
Origineel, FALSE: do_dat, do_iets_anders

Verbetering, TRUE: doe_dit
Verbetering, FALSE: doe_dat

Misschien dat in de "verbetering" ervanuitgegaan wordt dat stukken code uit het origineel gedupliceerd zijn in beide doe_() methodes, maar ik denk eerder dat het gebrek aan "break"'s werd gezien als een domme programmeur die dacht dat een gewone bool iets anders kan zijn naast TRUE en FALSE.

Het kan ook zijn dat ik op maandagmorgen niet helemaal wakker ben, maar zover ik het nu kan beoordelen zit er een kern van waarheid in mijn post

[mulder]

En bovendien moet je dan weten welke taal dit is of dat het pseudo code is. In C# zal het zelfs niet compileren

[EdwinG]

Het ontbreken van break was me nog niet eens opgevallen.
Startpost aangepast, zoals het er nu staat, zou de code hetzelfde resultaat moeten hebben, tenminste, als er echte booleans worden gebruikt.

[ Voor 16% gewijzigd door EdwinG op 30-10-2006 12:31 ]

[.oisyn]

Dit was makkelijker geweest:

code:

if (aBool)
    doe_dit();
doe_dat();
doe_iets_anders();

Maar dan nog, aangezien TRUE en FALSE gebruikt wordt ipv true en false lijkt het me meer een custom type, en dan kun je al weinig zeggen over de mogelijke states. Wellicht is het een int met TRUE=1 en FALSE=0, maar wat als er nou ook nog een INDETERMINATE=2 is? Dan gaat je if (aBool) al niet meer werken omdat die dan ook triggert bij een INDETERMINATE. De enige juiste wijze om het om te zetten naar een if is dan ook:

code:

if (aBool == TRUE)
   doe_dit();
if (aBool == TRUE || aBool == FALSE)
    doe_dat();
doe_iets_anders();

Iets zegt me dat dit al compleet voorbij je voorbeeld gaat, en dat je gewoon het standaard bool type bedoelde met break statements in de switch

[ Voor 78% gewijzigd door .oisyn op 30-10-2006 12:32 ]

[Anoniem: 183031]

prototype schreef op zaterdag 28 oktober 2006 @ 14:41:
[...]

Mjah, het is wel heel stoer natuurlijk dat je het kan schrijven , maar ik zie het nut er na 2 jaar nog steeds niet van in, i.e. in de praktijk gebruik ik het zelden. Daarbij is het bewijs c.q. de invariant vaak zo kryptisch geformuleerd dat het meer tijd kost om de invariant te begrijpen dan de lus zoals hij er staat. Maar goed, gelukkig hebben we die programmeervakken dan ook al lang in het verleden goed afgesloten en hoeven we er alleen nog maar uit nostalgische overwegingen naar terug te kijken

Hoewel het maar weinig gebruikt wordt zijn er wel degelijk situaties waar dergelijke bewijzen gebruikt worden. Deze worden echter meestal alleen maar gebruikt in kleine applicaties welke zeer kritisch kunnen zijn.
Denk hierbij bijvoorbeeld aan een smartcard (zoals bijvoorbeeld een chipknip) waarop een applicatie gedraaid kan worden. Je kan m.b.v. dergelijke technieken bewijzen dat het onmogelijk is om met een kaart te knoeien (niet dat dit voor een chipknip is bewezen, maar dat terzijde). Iets wat in sommige gevallen erg bruikbaar is.

Verder denk ik dat het goed is om het een keer gezien te hebben (Eindhoven blinkt daar volgens mij ook wel in uit ). Dat je het nut er niet van in ziet is erg jammer, hebben je docenten waarschijnlijk niet bereikt wat je zouden willen bereiken.

[EdwinG]

.oisyn schreef op maandag 30 oktober 2006 @ 12:27:
Dit was makkelijker geweest:

code:

if (aBool)
    doe_dit();
doe_dat();
doe_iets_anders();

Klopt ook nog, al houd die code geen rekening met NULL als mogelijke waarde.
Dat deed mijn wijziging trouwens ook niet, dus heb ik deze code maar neergezet.

[.oisyn]

Zie mijn edit trouwens.

[roy-t]

code:

If Jeugdigen.Geslacht = True Then txt_Geslacht.ListIndex = 1
If Jeugdigen.Geslacht = False Then txt_Geslacht.ListIndex = 0

imho is dit het stuk gekste code dat ik in tijden heb geschreven! ( een true boolean is een mannetje en een false een vrouwtje..)

zelfs moreel is dit voorbeeld fout! Maar het is dan wel weer een stukkie kleiner als een string*5 en daar ging het bij dit project om

edit: geslacht.. geslagt! EEP? ben ik nu nog compleet dyslectischer dan dat ik al was?! (of raak ik nu om niks in paniek)

[ Voor 12% gewijzigd door roy-t op 30-10-2006 14:15 ]

[.oisyn]

code:

if Koe.Geslacht Then VerkoopHetVlees()

[joepP]

Anoniem: 183031 schreef op maandag 30 oktober 2006 @ 12:28:
[...]

Hoewel het maar weinig gebruikt wordt zijn er wel degelijk situaties waar dergelijke bewijzen gebruikt worden. Deze worden echter meestal alleen maar gebruikt in kleine applicaties welke zeer kritisch kunnen zijn.
Denk hierbij bijvoorbeeld aan een smartcard (zoals bijvoorbeeld een chipknip) waarop een applicatie gedraaid kan worden. Je kan m.b.v. dergelijke technieken bewijzen dat het onmogelijk is om met een kaart te knoeien (niet dat dit voor een chipknip is bewezen, maar dat terzijde). Iets wat in sommige gevallen erg bruikbaar is.

Jaja. Eerst geef je een voorbeeld van mogelijke toepassing, daarna ontkracht je het weer.

Als onderzoekers nou eens toe zouden geven dat er ongeveer geen enkel maatschappelijk nut is voor correctheidsbewijzen van code zijn we al een hele stap verder. Het vakgebied is nu op een punt aangeland waarop wel duidelijk is geworden dat het eigenlijk niet mogelijk is code complexer dan een sorteeralgoritme correct te bewijzen. Praktijknut is nul komma nul. Zeker als je bekijkt hoeveel mensen hun denkkracht aan dit soort kulonderzoek hebben verprutst, en hoeveel geld dat gekost heeft, durf ik wel te stellen dat de wereld beter af zal zijn zonder dit vakgebied.

Sommige onderzoekers doen nou eenmaal het liefste dingen die ze zelf interessant vinden, en zijn daar heel goed in. Leuk. Maar probeer dat dan niet te verhullen door de zogenaamde "real world" er met de haren bij te slepen. Of argumenten in de trend van: "je leert op een andere manier denken, en dat is goed voor je ontwikkeling". Bah.

[Janoz]

@joepP:

Dat ben ik niet helemaal met je eens. Voordat je het onderzoek begint kun je onmogelijk voorspellen wat eruit gaat komen. Wat nu als al dat onderzoek daadwerkelijk had geleid tot een automatische methode om de correctheid van software te bewijzen dan was dat een behoorlijke doorbraak geweest, maar goed, het is een beetje vergelijkbaar met dat computers ook nog niet zelfstandig complete vergelijkingen op kunnen lossen.

Ook over de andere manier van denken ben ik het niet met je eens. Nadat je uitgebreid les hebt gehad in correctheids bewijzen kijk je toch iets anders tegen een for lusje aan om het maar even wat simpel uit te drukken. Net zo als Wiskunde A je op de middelbare school wat inzichten bijbrengt zodat je je hypotheek wat sneller kunt begrijpen zal ook het bewijzen van de correctheid van een stuk code je bepaalde tools hebben aangeleerd om bepaalde bugs sneller te spotten. Dat betekent natuurlijk niet dat je de rest van je leven pre en post condities loopt te schrijven en deze compleet gaat afleiden.

[Anoniem: 183031]

joepP schreef op maandag 30 oktober 2006 @ 13:06:
[...]

Jaja. Eerst geef je een voorbeeld van mogelijke toepassing, daarna ontkracht je het weer.

Ik beschrijf een domein waarbij de techniek gebruikt kan worden. Als voorbeeld geef ik aan dat de chipknip een smartcard is waar dit voor gedaan kan worden maar waar het niet voor gedaan is (ik denk dat het overigens wel een goede zaak zou zijn). Er zijn echter andere smartcard applicaties waarvoor dit soort bewijzen wel zijn gegeven.

Als onderzoekers nou eens toe zouden geven dat er ongeveer geen enkel maatschappelijk nut is voor correctheidsbewijzen van code zijn we al een hele stap verder. Het vakgebied is nu op een punt aangeland waarop wel duidelijk is geworden dat het eigenlijk niet mogelijk is code complexer dan een sorteeralgoritme correct te bewijzen. Praktijknut is nul komma nul. Zeker als je bekijkt hoeveel mensen hun denkkracht aan dit soort kulonderzoek hebben verprutst, en hoeveel geld dat gekost heeft, durf ik wel te stellen dat de wereld beter af zal zijn zonder dit vakgebied.

Over maatschappelijk nut gesproken... ik denk dat er dus wel toepassingsmogelijkheden zijn al heb je gelijk dat het toepassingsgebied maar zeer beperkt is. Als het mogelijk is om zo te bewijzen dat een chipknip bijvoorbeeld "safe" is dan zou dat een goede zaak zijn en ben ik daar zeker voorstander van in plaats van de nu toegepaste "methode" security by obscurity.

Helaas is het niet mogelijk om vooraf van een onbekend onderzoeksgebied te weten of het iets op gaat leveren. Soms levert het leuke en goede resultaten op, soms wat mindere. Als een onderzoeksgebied niets oplevert zal er ook geen geld meer voor worden vrijgemaakt en steft het vanzelf uit. Dat jij je daar zo aan stoort... ja da's vervelend

Sommige onderzoekers doen nou eenmaal het liefste dingen die ze zelf interessant vinden, en zijn daar heel goed in. Leuk. Maar probeer dat dan niet te verhullen door de zogenaamde "real world" er met de haren bij te slepen. Of argumenten in de trend van: "je leert op een andere manier denken, en dat is goed voor je ontwikkeling". Bah.

Ik proef een bepaalde aversie tegen onderzoekers

Gelukkig ben ik zelf geen onderzoeker

[Anoniem: 64834]

@joepP

Ik ben het net zo als Janoz niet helemaal eens met je betoog.

Ten eerste is het tegenwoordig best wel mogelijk om ingewikkeldere dingen te bewijzen dan een sorteer algoritme. De bewijzen zijn daarvoor misschien niet zo waterdicht als met Hoare logica, maar toch is dat vaak al genoeg om jezelf (of iemand anders) te overtuigen dat je in de goede richting zit.

Ten tweede het zal nog zeker enkele decenia duren voordat er volledig automatisch kwaliteit kan worden gegarandeerd voor willekeurige software. Ik verwacht tegen die tijd dat kwaliteit wordt gegarandeerd aan de hand van verificatie van de requirements, hoewel daar nog wat haken en ogen aan zitten. Bijv, hoe behandel je gebruikersinvoer of grafische uitvoer? Het grootste probleem is en zal nog lang blijven dat software te veel toestanden kent.

Als laatste vind ik dat correctheidsbewijzen toch best nuttig, maar vooral de andere kant op. Middels correctheidsbewijzen is het met de juiste technieken mogelijk om efficiente code te krijgen (waar je zonder afleiding geen touw aan vast kunt knopen).
Aan de andere kant kan het je helpen bij vragen als 'moet het nou n zijn of n+1', eenvoudige vragen die je koppijn kunnen opleveren kun je dan toch oplossen.

[Anoniem: 57381]

Om dicht bij het topic te blijven.... ik win!

code:

#include "stdio.h"
#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))

long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };

main(m1,s) char *s; {
    int a,b,c,d,o[k],n=(int)s;
    if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
    else switch(m1-=h){
        case f:
            a=(b=(c=(d=g)<<g)<'<g)<<g;
            return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
        case h:
            for(a=f;a=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
            return(o[b-g]%n+k-h);
        default:
            if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
            for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
        }
}

Deze code werkt prima! De eerste die weet wat het doet zonder het uit te voeren krijgt eeuwige roem in dit topic!

[Anoniem: 64834]

[ Voor 100% gewijzigd door Anoniem: 64834 op 30-10-2006 14:08 ]

[roy-t]

Anoniem: 57381 schreef op maandag 30 oktober 2006 @ 13:55:
Om dicht bij het topic te blijven.... ik win!

code:

#include "stdio.h"
#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))

long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };

main(m1,s) char *s; {
    int a,b,c,d,o[k],n=(int)s;
    if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
    else switch(m1-=h){
        case f:
            a=(b=(c=(d=g)<<g)<'<g)<<g;
            return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
        case h:
            for(a=f;a=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
            return(o[b-g]%n+k-h);
        default:
            if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
            for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
        }
}

Deze code werkt prima! De eerste die weet wat het doet zonder het uit te voeren krijgt eeuwige roem in dit topic!

Nou ben ik geen C-er, maar sorteert dit stukje code 2 rijtjes getallen en vergelijkt ze dan met elkaar om tot een bepaade uitvoer te komen? offf eehhh... *geeft het op*

(goh wat zou ik lachen als je je code zo afmaakt en daarna het aan de volgende programmeur geeft, "maak jij dit even af... er moetne nog een paar o'tjes en g'tjes in" )

[TheNameless]

Anoniem: 57381 schreef op maandag 30 oktober 2006 @ 13:55:
Om dicht bij het topic te blijven.... ik win!

code:

#include "stdio.h"
#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))

long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };

main(m1,s) char *s; {
    int a,b,c,d,o[k],n=(int)s;
    if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
    else switch(m1-=h){
        case f:
            a=(b=(c=(d=g)<<g)<'<g)<<g;
            return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
        case h:
            for(a=f;a=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
            return(o[b-g]%n+k-h);
        default:
            if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
            for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
        }
}

Deze code werkt prima! De eerste die weet wat het doet zonder het uit te voeren krijgt eeuwige roem in dit topic!

Alleen jammer dat het niet compiled

[.oisyn]

Idd, er zit een ' op regel 19 die daar niet hoort, en de forlussen zonder increment gedeelte (en dan doel ik dus op de missende accolade) zijn een beetje vaag.

[ Voor 95% gewijzigd door .oisyn op 30-10-2006 14:51 ]

[Maestro.mosjuh]

2 voorbeelden van (java) code die niet fout zijn, maar waar ik wel mijn vraagtekens bij zet....

Java:

Session session = session = new Session();

Java:

Object object = getFiets();
Fiets fiets = (Fiets)object;

Overigens een fout die ik nog wel eens wil maken (en al eerder in de topicreeks genoemd is) is het vergeten van een var++. Voorbeeld:

Java:

private void doeIets(){
   int i = 0;
   while(i<10){
      // doe iets
   }
}

Maargoed, die heb je wel snel door als je weer eens zit te wachten en je afvraagt waarom de operatie zo lang duurt.
_{en tegenwoordig gebruik ik bijna altijd "for(int i = 0; i < 10; i++)"}

[ Voor 5% gewijzigd door Maestro.mosjuh op 30-10-2006 15:06 ]

[prototype]

Anoniem: 183031 schreef op maandag 30 oktober 2006 @ 12:28:
[...]

Hoewel het maar weinig gebruikt wordt zijn er wel degelijk situaties waar dergelijke bewijzen gebruikt worden. Deze worden echter meestal alleen maar gebruikt in kleine applicaties welke zeer kritisch kunnen zijn.

En daarmee staat mijn punt nog steeds dat het in de praktijk zelden echt waarde heeft.

Denk hierbij bijvoorbeeld aan een smartcard (zoals bijvoorbeeld een chipknip) waarop een applicatie gedraaid kan worden. Je kan m.b.v. dergelijke technieken bewijzen dat het onmogelijk is om met een kaart te knoeien (niet dat dit voor een chipknip is bewezen, maar dat terzijde). Iets wat in sommige gevallen erg bruikbaar is.

Een programmeur, i.e. mens formuleert een dergelijk bewijs, en daarmee kan het bewijs evenzo ook fout zijn (en dat dit onopgemerkt voorbij gaat). Dan zou ik in dat geval in een praktijk situatie zoiets liever niet alleen af laten hangen van een dergelijk bewijs, maar ook bekrachtigen met een intensieve testcase (eventueel als supplement van de invariant indien mogelijk, als het b.v. uitmaakt van de postconditie).

Verder denk ik dat het goed is om het een keer gezien te hebben (Eindhoven blinkt daar volgens mij ook wel in uit ). Dat je het nut er niet van in ziet is erg jammer, hebben je docenten waarschijnlijk niet bereikt wat je zouden willen bereiken.

Toegegeven, het geeft je wel wat meer inzichten mbt lussen (UTwente is daar overigens ook niet heel zuinig mee, P1'ers worden ermee doodgegooid) en zoals Janoz al zei, je kijkt al gauw anders tegen zo'n lus. Dat wil echter niet zeggen dat ik voor elke lus een dergelijk bewijs ga formuleren . Don't get me wrong, misschien heb ik me ietwat verkeerd uitgedrukt (alhoewel ik toch duidelijk ben volgens mij in het praktische nut), ik zie het nut er opzich wel van in (zij het van een meer wiskundig aspect), maar nogmaals in de praktijk zoals ik die tot op heden heb ervaren echter nog niet zo snel. Dit kan uiteraard evengoed komen door het soort applicaties dat ik tot op heden voornamelijk heb moet bouwen en het tijdsbestek dat hieraan gegeven wordt in de praktijk. Misschien komt dat ooit nog wel, als het er iig van komt, dan heb ik het iig wel achter de kiezen

[ Voor 7% gewijzigd door prototype op 30-10-2006 15:35 ]

[Anoniem: 183031]

En daarmee staat mijn punt nog steeds dat het in de praktijk zelden echt waarde heeft.

Toch ben ik van mening dat het in de toekomst meer en meer waarde zal krijgen. Ten eerste zijn er dus wel degelijk situaties waarbij er gebruik van gemaakt kan worden (met eventueel nut) en ten tweede zullen er in de toekomst vast en zeker vervolg-onderzoeken worden gestart die weer een stapje verder komen (sorry joepP ).

Een programmeur, i.e. mens formuleert een dergelijk bewijs, en daarmee kan het bewijs evenzo ook fout zijn (en dat dit onopgemerkt voorbij gaat). Dan zou ik in dat geval in een praktijk situatie zoiets liever niet alleen af laten hangen van een dergelijk bewijs, maar ook bekrachtigen met een intensieve testcase (eventueel als supplement van de invariant indien mogelijk, als het b.v. uitmaakt van de postconditie).

Met behulp van een bewijs en wat automaten logica zou je een heel eind moeten kunnen komen om de hele state space af te dekken. Echter staat dit onderzoeksgebied ook nog in de "kinderschoenen" waardoor dit ook nog niet mogelijk is voor grote systemen. In de toekomst verwacht ik echter dat dit voor steeds grotere systemen mogelijk wordt.

Toegegeven, het geeft je wel wat meer inzichten mbt lussen (UTwente is daar overigens ook niet heel zuinig mee, P1'ers worden ermee doodgegooid) en zoals Janoz al zei, je kijkt al gauw anders tegen zo'n lus. Dat wil echter niet zeggen dat ik voor elke lus een dergelijk bewijs ga formuleren . Don't get me wrong, ik zie het nut er opzich wel van in (zij het van een meer wiskundig aspect), maar zoals eerder gezegd, in de praktijk zoals ik die tot op heden heb ervaren echter nog niet zo snel. Dit kan uiteraard evengoed komen door het soort applicaties dat ik tot op heden voornamelijk heb moet bouwen en het tijdsbestek dat hieraan gegeven wordt in de praktijk. Misschien komt dat ooit nog wel, als het er iig van komt, dan heb ik het iig wel achter de kiezen

Niemand zal verwachten dat je telkens een dergelijk bewijs gaat formuleren. Ik denk echter dat het wel goed is dat je een keer nadenkt over een dergelijk bewijs.

Op het HBO heb ik mensen gezien die letterlijk niet wisten wat ze aan het programmeren waren... vervolgens kreeg ik op de universiteit dergelijke bewijzen te zien. Ik dacht toen bij mezelf, je zou hen deze bewijzen eens moeten voorschotelen, daar zouden ze veel van kunnen leren. Dus nee, niet iedere lus bewijzen m.b.v. invarianten maar er wel eens bij stil staan waarom het werkt zoals het werkt

[Anoniem: 57381]

.oisyn schreef op maandag 30 oktober 2006 @ 14:47:
Idd, er zit een ' op regel 19 die daar niet hoort, en de forlussen zonder increment gedeelte (en dan doel ik dus op de missende accolade) zijn een beetje vaag.

Is code uit 1986 misschien dat het werkt met een compiler uit die tijd? die ' zou een achterblijfsel uit een mail kunnen zijn waarmee de code vervoerd is geworden.

Nog niemand dus die eeuwige roem in dit toptic weet te vergaren? Terwijl dit toch echt zo'n beetje het eerste is wat je leert. Nou ja, zo ongeveer dan....

[Soultaker]

Als ik 'm door de C preprocessor mag halen wil ik er wel een gooi naar doen, maar in deze vorm begin ik er echt niet aan. (Geen zin om handmatig de preprocessor uit te hangen om leesbare code te produceren.)

[PhysicsRules]

@Hasse: die code produceert vast en zeker het antwoord op alle vragen: 42 !

[Anoniem: 57381]

PhysicsRules schreef op maandag 30 oktober 2006 @ 16:14:
@Hasse: die code produceert vast en zeker het antwoord op alle vragen: 42 !

Haha, ja dat zou mooi zijn! Ik heb daar net een hele discussie overgehad tijdens de lunch, niemand kende dat hier.....

Anyhow, ik heb het antwoord hier neergezet voor de mensen die het echt zelf kunnen bedenken. Voor de anderen: puzzel maar lekker verder en als je niet meer kunt wachten, klikkerdeklik op de link.

[wacco]

Anoniem: 57381 schreef op maandag 30 oktober 2006 @ 13:55:
Om dicht bij het topic te blijven.... ik win!

code:

...

Deze code werkt prima! De eerste die weet wat het doet zonder het uit te voeren krijgt eeuwige roem in dit topic!

Volgens mij heb je 'em dus zelf niet uitgeprobeerd. Anyway, het lijkt heel sterk op een misvormde versie van Bruce Holloway's hello world (google doet wonderen als je wijs over wilt komen ) welke in 1986 mee deed met de IOCCC.

http://www.ioccc.org/1986/holloway.c

En die compiled wel zonder problemen.

[LuCarD]

Anoniem: 57381 schreef op maandag 30 oktober 2006 @ 13:55:
Om dicht bij het topic te blijven.... ik win!

code:

#include "stdio.h"
#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))

long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };

main(m1,s) char *s; {
    int a,b,c,d,o[k],n=(int)s;
    if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
    else switch(m1-=h){
        case f:
            a=(b=(c=(d=g)<<g)<'<g)<<g;
            return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
        case h:
            for(a=f;a=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
            return(o[b-g]%n+k-h);
        default:
            if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
            for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
        }
}

Deze code werkt prima! De eerste die weet wat het doet zonder het uit te voeren krijgt eeuwige roem in dit topic!

Goed jij wint je bent de slechtste programmeur van GOT

[Anoniem: 64834]

Wat een anti-climax

[TeeDee]

LuCarD schreef op maandag 30 oktober 2006 @ 16:26:
[...]
Goed jij wint je bent de slechtste programmeur van GOT

Uhm, nee. Zie de reactie van wacco.

kreeg de indruk dat Hasse deze code als zijn eigen code wilde plaatsen. Nofi

[Anoniem: 57381]

wacco schreef op maandag 30 oktober 2006 @ 16:26:
[...]

Volgens mij heb je 'em dus zelf niet uitgeprobeerd. Anyway, het lijkt heel sterk op een misvormde versie van Bruce Holloway's hello world (google doet wonderen als je wijs over wilt komen ) welke in 1986 mee deed met de IOCCC.

http://www.ioccc.org/1986/holloway.c

En die compiled wel zonder problemen.

Ik vond het nogal lang duren vorodat iemand die code in google flikkerde...in plaats van in zijn compiler... gelukkig maar dat ik dan niet de slechtste programmeur van GoT ben. Zoals een goed programmeur betaamt kun je goede code beter 'lenen' dan proberen opnieuw uit te vinden...

[ Voor 7% gewijzigd door Anoniem: 57381 op 30-10-2006 17:03 ]

[Robtimus]

Maestro.mosjuh schreef op maandag 30 oktober 2006 @ 15:03:
Overigens een fout die ik nog wel eens wil maken (en al eerder in de topicreeks genoemd is) is het vergeten van een var++. Voorbeeld:

Java:

private void doeIets(){
   int i = 0;
   while(i<10){
      // doe iets
   }
}

Daar heb ik nog wel eens last van als ik in VB6 met databases werk.

Java:

ResultSet rs = ...;
while (rs.next()) // zoekt automatisch het volgende record op
{
    // code
}

versus

Visual Basic:

adoRS.Open ...
Do Until adoRS.EOF
    ' code
    adoRS.MoveNext ' <- die vergeet ik dus nog wel eens
Loop

Dan krijg je idd van die eternal loops.

[elTigro]

Een eternal loop! Zou ie echt eternally blijven lopen? Of zou ie op een gegeven moment toch wel eens stoppen? (Als de pc crasht ofzo... )

Vandeweek zag ik bij iemand hier dit mooie stukje scriptwerk. (heeft toch ook 'n beetje met programmeren te maken.)

code:

#!/bin/bash
#start

date=`Date +%D`
filepost=`echo $date | sed 's/\//\ /g'| awk '{print $2 $1 "20" $3}'`
cd /waar/dan/ook
tar cf eenofanderfilemetdatum${filepost}.tar eendir
echo "gzip -c eenofanderfilemetdatum${filepost}.tar  > eenofanderfilemetdatum$....tar.[b]gz[/b]" >a
chmod 755 a
source a
echo "cp eenofanderfilemetdatum${filepost}.tar.gz ~wiedanook/public_html/eenofanderfile.tar.gz"  >b
chmod 755 b
source b
\rm -f a b

Waar ik zelf het meest van gecharmeerd ben is die #start en de prachtige manier om de datum te verhusselen. En je kunt zeggen wat je wilt, maar in princiepe vind ik het niet eens zo heel erg slecht. Er wordt ten slotte aan het einde nog netjes opgeruimd.

Gehakt schreef op vrijdag 27 oktober 2006 @ 13:01:
Is het misschien een idee om er gelijk bij te zetten hoe het wel moet? Of iig de reden waarom iets gruwelijk fout is? ...

Ik vind het dus in princiepe niet gruwelijk fout, dus ja, verbeteringen?
Maar als ik het zelf gemaakt zou hebben zou ik denk ik date iets anders aangeroepen hebben en de output niet in een var douwen

code:

` date +%d%m%Y `

en ik denk dat ik tar ook de optie z zou hebben meegegeven. Scheelt in ieder geval weer het aanmaken en sourcen (prachtig, er wordt te weinig gesourced tegenwoordig) van filetje a.

[MTWZZ]

Visual Basic:

adoRS.Open ...
Do Until adoRS.EOF
    ' code
    adoRS.MoveNext ' <- die vergeet ik dus nog wel eens
Loop

^^ nare shit dat

[Confusion]

wacco schreef op maandag 30 oktober 2006 @ 16:26:
Anyway, het lijkt heel sterk op een misvormde versie van Bruce Holloway's hello world (google doet wonderen als je wijs over wilt komen ) welke in 1986 mee deed met de IOCCC.

Voor een IOCCC vind ik hem trouwens niet zo heel sterk; dit kan iedere programmeur zelf produceren met zeer beperkte kennis van C. Deze code vereist alleen tijd om het op te lossen, geen diep begrip. Tussen die IOCCC's zitten dingen waarvan ik uberhaupt niet begrijp waarom het een bepaald antwoord oplevert; soms zelfs niet waarom het compileert.

[S2K]

IceManX schreef op vrijdag 27 oktober 2006 @ 22:02:
[...]
* S2K heeft Technische Informatica aan de TU/e gedaan - les gehad van de Dijkstal fanatici wijlen Van Gasteren, Hoogerwoord en Feijen.

Ik vrees dat Edsger W. Dijkstra zich nu in zijn graf omdraait dat zijn naam zo verbasterd word.

[.oisyn]

Menig docent Nederlands eveneens, door de grammaticafout in je post.