Safe & secure programming

[Verwijderd]

Ivo, dat lijkt me een vrij zinloos gebruik van een goto... Wat is er mis met:

Delphi:

val := -1;
for i := 0 to List.Count - 1 do begin
  if (P(List[i]) then begin
    val := i;
    break;
  end
end;
Assert((val > -1), 'we didnt find an item in List satisfying P');
// Do some other stuff

Dan gebruik je Assert() ook nog waar 't voor bedoeld is: checken of iets mag, en zo nee een exception raisen.

[ Voor 5% gewijzigd door Verwijderd op 30-05-2006 20:46 ]

[.oisyn]

Ivo schreef op dinsdag 30 mei 2006 @ 19:12:
Waarom zijn goto's achterhaald? Even een Delphi-voorbeeld analoog aan wat ik vandaag nodig had.

Dan had je even wat harder na moeten denken.

Delphi:

for i := 0 to List.Count - 1 do
begin
  if (P(List[i]) then
  begin
     //Do some other stuff
  end
end;
Assert(False,'we didnt find an item in List satisfying P');

Of nog beter, de conditie checken in je assert zelf.

Dit is de reden waarom in Python de for-else constructie is ingevoerd.

Geldt dat niet alleen als die range leeg is (of in het algemeen: als de for geen enkele iteratie doorloopt). Als er een range bestaat doorloopt ie weldegelijk iteraties, waarvan de meeste gecanceled worden in de eerstvolgende if. Lijkt me stug dat die else wordt uitgevoerd zodra alle condities in die eerste if false opleveren.

.edit: ah, heb het even opgezocht, de else wordt altijd uitgevoerd, tenzij je uit de lus breakt. Best handig

[ Voor 10% gewijzigd door .oisyn op 30-05-2006 20:51 ]

[Verwijderd]

.Oisyn, dan zul toch na die "//Do some otther stuff" uit de for-lus moeten springen en die Assert() ontwijken.

[.oisyn]

Ja, met een return bijvoorbeeld

[Ivo]

Ja, in dit pseudocode geval kon het makkelijk anders, maar de do_some_oher_stuff was erg groot in dit geval en die heb je liever niet zo diep geindenteerd.

[Creepy]

De grootte van een stuk code maakt het ok om een goto te gebruiken op een plek waar deze totaal niet nodig is? Vaak kan je door slim je code op te splitsen en het weer in te delen in kleinere (logische) delen je code een stuk beter leesbaar maken in vergelijking met die lap code en een goto
En met een indeling in iets meer functies heb je ook meteen het probleem van (te) diepe nesting al deels opgelost. Dit is ook een reden waarom er bedrijven zijn die als onderdeel van een coding standaard hebben opgenomen dat een functie/method niet langer mag zijn dan x regels bijv. Zo wordt je gedwongen om je code logisch in te delen i.p.v. er 1 lange lap van te maken.

[Ivo]

Als ik het stuk bewuste code opzoek dan had het inderdaad gekund, zoals AfterLife zei, maar de goto is daar in principe op zijn plaats.

Delphi:

        for i := 0 to Length(Adjs) - 1 do
        begin
          for j := 0 to Length(Adjs[i]) - 1 do
          begin
            ID := Adjs[i][j];
            for h := 0 to Areas.Count - 1 do
            begin
              if ((Areas.Items[h] as TArea).FID = ID) then
              begin
                  a := h;
                    goto out_here;
              end
            end;
            Assert(False);
          out_here:
            (Areas.Items[i] as TArea).FAdjacentAreas.Add(Areas.Items[a]);
          end;
        end;

In principe wil je een `break 2' uitvoeren, maar dat gaat in Delphi niet zover ik weet.

[ Voor 7% gewijzigd door Ivo op 30-05-2006 23:53 ]

[.oisyn]

Ivo schreef op dinsdag 30 mei 2006 @ 23:08:
Ja, in dit pseudocode geval kon het makkelijk anders, maar de do_some_oher_stuff was erg groot in dit geval en die heb je liever niet zo diep geindenteerd.

Een perfecte kandidaat voor een functie dus? Daarnaast zei kwam Afterlife met een voorbeeld dat ik ook aankaartte: checken op val==-1 in de Assert. Een assert heeft niet voor niets een dergelijke constructie

Daarnaast kun je ook vaak gewoon variabelen gebruiken om uit meerdere nesten diep te springen (mocht de taal daar niet in voorzien muv goto):

C++:

void foo()
{
    bool found = false;

    for (int i = 0; !found && i < x; i++)
    {
        for (int j = 0; !found && j < y; j++)
        {
            for (int k = 0; k < z; k++)
            {
                if (condition(i, j, k))
                {
                    found = true;
                    break;
                }
            }
        }
    }

    if (!found)
    {
        error();
        return;
    }

    // do some stuff
}

Efficientie is geen issue, een goede C++ compiler zal hier handelen alsof je gewoon een goto hebt gebruikt.

goto is maar voor één ding echt bruikbaar, en dat is voor gegenereerde code (bijv. compilers die script code omzetten naar C of C++ code). De overige gevallen dat je ze nodig hebt zijn echt extreem zeldzaam (ik geloof dat ik 'm in de afgelopen 10 jaar 1x heb gebruikt, en zelfs toen was het twijfelachtig). Sommige talen kennen zelfs geeneens een goto, Java bijvoorbeeld.

[ Voor 15% gewijzigd door .oisyn op 30-05-2006 23:59 ]

[Grijze Vos]

Ik ben het met .oisyn eens moet ik zeggen. Mijn indenting ziet er meestal zo uit:

PHP:

if($drink->type == beer)
{ // Zuip je klem
  zuip($drink);
}
else
{ // iets anders 
  ...etc
}

Ivm debugging is het heel fijn, en ik heb meteen een goed plekkie in de code voor wat commentaar.

Overigens, over dat breaken uit code-blokken. Ikzelf doe het ook regelmatig in mijn php code, omdat ik het wel makkelijk vind. Maar als je het echt netjes wilt doen dan zet je een boolean in je guard erbij natuurlijk.

[ Voor 27% gewijzigd door Grijze Vos op 30-05-2006 23:59 ]

[MSalters]

igmar schreef op dinsdag 30 mei 2006 @ 13:37:
[...]
[Functies nooit aanroepen met berekeningen in de parameter list (drukaf(2*b+1);)]

Dit heeft er meer mee te maken dat in C je geen waarde van een object meer dan 1 keer mag veranderen zonder sequence point :

C:

a[i] = i++;

geeft dus undefined behaviour.

Staat volledig los van elkaar. In C heb je een sequence point bij de aanroep van een functie, nadat alle parameters zijn geevalueerd en voordat het eerste statement in de functie wordt uitgevoerd. In jouw voorbeeld wordt er geen functie aangeroepen. Bovendien leveren pure berekeningen als (2*b+1) geen sideeffects op, en staan ze dus sowieso los van sequence points.

[igmar]

MSalters schreef op woensdag 31 mei 2006 @ 00:35:
[...]

Staat volledig los van elkaar. In C heb je een sequence point bij de aanroep van een functie, nadat alle parameters zijn geevalueerd en voordat het eerste statement in de functie wordt uitgevoerd. In jouw voorbeeld wordt er geen functie aangeroepen.

Hoezo is dat relevant ? In mijn voorbeeld modificeer je nog steeds 2 keer dezelfde variabele zonder een sequence point, die pas eindigd na de ; Da's undefined behaviour, da's mijn punt, en dat ben ik wel eens tegengekomen in functieaanroepen.

Goed, ik deel het standpunt niet dat je geen berekeing in je argumenten moet doen, maar mijn voorbeeld heb ik soortgelijk wel eens in code gezien. Een groter gevaar is macro's in argumenten als je het mij vraagt.


Bovendien leveren pure berekeningen als (2*b+1) geen sideeffects op, en staan ze dus sowieso los van sequence points.[/quote]

[The - DDD]

Janoz schreef op dinsdag 30 mei 2006 @ 15:54:
Ik denk dat hamsteggot met kritisch hier meer embedded en realtime applicaties bedoeldt.

Toch wel grappig wanneer je bedenkt dat Java oorspronkelijk ontwikkeld is als oplossing voor embedded en realtime toepassingen.

He wat? Ja serieus, daar is Java oorspronkelijk voor ontwikkeld.

Voorbeelden embedded: Mobiele telefoons, Java is de grootste speler op die markt.
Voorbeelden realtime: ben er niet zo in thuis, maar er zijn vast uitstekende realtime Java oplossingen te vinden waarin je meer controlle hebt over scheduling gerelateerde zaken. Om nog maar niet te beginnen over semi realtime systemen.

Overigens is de snelheid van Java niet een discussie waar ik aan wil beginnen. Persoonlijk heb ik absoluut geen problemen mee. Want ik bouw geen systemen waarin ik die absolute controle nodig heb. Er zijn denk ik extreem weinig toepassingen te bedenken die echt keiharde realtime restricties hebben. In de meeste gevallen zal een verwerking binnen een miniem kleine tijdspanne al voldoende zijn en maakt het niet uit of dit een milliseconde eerder of later is, als het maar binnen x milliseconden gebeurt.

Edit: Of begin ik nu toch een discussie. In dat geval: never mind, terug on-topic.

[ Voor 4% gewijzigd door The - DDD op 31-05-2006 10:49 ]

[The - DDD]

igmar schreef op woensdag 31 mei 2006 @ 08:39:
[...]


... Een groter gevaar is macro's in argumenten als je het mij vraagt.
...

Dus een kwestie van clean macro's definiëren. Als in (veel (haakjes (gebruiken))).

offtopic:
Hehe, eindelijk snap ik weer hoe ik moet posten

[ Voor 30% gewijzigd door The - DDD op 31-05-2006 10:54 ]

[Exirion]

.oisyn schreef op maandag 29 mei 2006 @ 23:21:
En leuk, dat voorbeeld van de 386, maar je loopt daar even aan het feit voorbij dat de gemiddelde applicatie van toen slechts een fractie van de hoeveelheid code waren van de applicaties van nu.

Nou en? Zijn statement/mening blijft daarmee nogsteeds overeind. Hij zegt precies wat jij ook zegt: de verhouding tussen code size/complexity en processing speed loopt scheef. Aan die size/complexity kun je zeker wat doen, maar onderhand is iedereen het er ook wel overeens dat veel software net zo goed qua performance slecht in elkaar steekt.

Jij maakt je met het verdedigende argument 'jah, maar vroeger was alles ook veel korter en simpeler' net zo schuldig aan performance-verloedering als veel hedendaagse ontwikkelaars. Ik erger me vaak aan mensen, ook collega's, die maar blijven roepen dat computer snel zat zijn dus dat het niet boeit. Onzin! Feit is en blijft dat, ondanks de enorm toegenomen mogelijkheden, veel mensen zich eraan erger dat alles op die oude DOS PC toch sneller ging dan met de moderne PC met x GHz, x GB RAM en een paar honderd GB aan harddisks. Daar kun je moeilijk je ogen voor sluiten.

Ik vind dat teveel ontwikkelaars vanuit hun eigen perspectief naar software kijken en niet door de ogen van de gebruiker.

[Ivo]

igmar schreef op woensdag 31 mei 2006 @ 08:39:
[...]


Hoezo is dat relevant ? In mijn voorbeeld modificeer je nog steeds 2 keer dezelfde variabele zonder een sequence point, die pas eindigd na de ; Da's undefined behaviour, da's mijn punt, en dat ben ik wel eens tegengekomen in functieaanroepen.

Goed, ik deel het standpunt niet dat je geen berekeing in je argumenten moet doen, maar mijn voorbeeld heb ik soortgelijk wel eens in code gezien. Een groter gevaar is macro's in argumenten als je het mij vraagt.


Bovendien leveren pure berekeningen als (2*b+1) geen sideeffects op, en staan ze dus sowieso los van sequence points.

code:

a[i] = i++;

Dit levert helemaal geen ongedefinieerd gedrag op. Dit is equivalent aan:

code:

a[i] = i; i++;

[ Voor 4% gewijzigd door Ivo op 31-05-2006 11:11 ]

[.oisyn]

Exirion schreef op woensdag 31 mei 2006 @ 11:04:
Jij maakt je met het verdedigende argument 'jah, maar vroeger was alles ook veel korter en simpeler' net zo schuldig aan performance-verloedering als veel hedendaagse ontwikkelaars.

Toch beter lezen dan. Ik stel dat onderhoudbaarheid en ease of use van code en libraries met grote projecten belangrijker is dan bij kleine projecten. In dat opzicht lever je wat voor performance in, maar win je tegelijkertijd met development-tijd en onderhoud. Dat er ondertussen applicaties worden ontwikkeld die "ranzig traag" zijn (maar niet zo ervaren worden omdat CPU's toch snel genoeg zijn) omdat er geen aandacht is besteed aan het schrijven van degelijke code ontken ik helemaal niet; die applicaties zijn er wel degelijk, en daar zijn er waarschijnlijk ook teveel van. Die wil ik helemaal niet verdedigen, het ging mij slechts om de eerste paar regels van dit relaas.

[ Voor 14% gewijzigd door .oisyn op 31-05-2006 11:14 ]

[Janoz]

The - DDD schreef op woensdag 31 mei 2006 @ 10:48:
Toch wel grappig wanneer je bedenkt dat Java oorspronkelijk ontwikkeld is als oplossing voor embedded en realtime toepassingen.

He wat? Ja serieus, daar is Java oorspronkelijk voor ontwikkeld.

StarSeven

Voorbeelden embedded: Mobiele telefoons, Java is de grootste speler op die markt.

Bij embedded moet je meer denken aan de firmware van een mobiele telefoon, niet aan de applicaties die je er op draait. Hiervoor wordt java nog niet tot nauwelijks gebruikt.

Voorbeelden realtime: ben er niet zo in thuis, maar er zijn vast uitstekende realtime Java oplossingen te vinden waarin je meer controlle hebt over scheduling gerelateerde zaken. Om nog maar niet te beginnen over semi realtime systemen.

Bij realtime is het van belang dat je exacte garanties kunt geven wanneer iets gebeurt en wanneer wordt aangegeven dat dit niet gaat lukken. De specificaties van de VM staan dit niet toe. Er zijn wel wegen omheen (door een nieuwe VM te schrijven die extra garanties biedt), maar dan blijft nog wel staan dat java niet de geschikte taal is voor realtime toepassingen.

Overigens is de snelheid van Java niet een discussie waar ik aan wil beginnen. Persoonlijk heb ik absoluut geen problemen mee.

Dat is ook 1 van de grote it mythen en enkel veroorzaakt door de applets eind vorige eeuw. In principe zegt het al genoeg dat MS voor .net eenzelfde executie structuur heeft gekozen.

[Exirion]

.oisyn schreef op woensdag 31 mei 2006 @ 11:11:
Toch beter lezen dan. Ik stel dat onderhoudbaarheid en ease of use van code en libraries met grote projecten belangrijker is dan bij kleine projecten. In dat opzicht lever je wat voor performance in, maar win je tegelijkertijd met development-tijd en onderhoud. Dat er ondertussen applicaties worden ontwikkeld die "ranzig traag" zijn (maar niet zo ervaren worden omdat CPU's toch snel genoeg zijn) omdat er geen aandacht is besteed aan het schrijven van degelijke code ontken ik helemaal niet; die applicaties zijn er wel degelijk, en daar zijn er waarschijnlijk ook teveel van. Die wil ik helemaal niet verdedigen, het ging mij slechts om de eerste paar regels van dit relaas.

Ok, dan snap ik je. Blijkbaar plaatste ik je uitspraak in een te ruime context

[Verwijderd]

.oisyn schreef op dinsdag 30 mei 2006 @ 23:56:
Daarnaast kun je ook vaak gewoon variabelen gebruiken om uit meerdere nesten diep te springen (mocht de taal daar niet in voorzien muv goto):

C++:

void foo()
{
    bool found = false;

    for (int i = 0; !found && i < x; i++)
    {
        for (int j = 0; !found && j < y; j++)
        {
            for (int k = 0; k < z; k++)
            {
                if (condition(i, j, k))
                {
                    found = true;
                    break;
                }
            }
        }
    }

    if (!found)
    {
        error();
        return;
    }

    // do some stuff
}

Delphi for-loops ondersteunen zo'n "!found &&" constructie niet, maar met een while-loop is 't ook wel elegant op te lossen:

Delphi:

procedure Foo
var
  i, j, k: integer;
  Found: boolean;
begin
  i := -1;
  j := -1;
  k := -1;
  Found := False;
  while ((not Found) and (i < x-1)) do begin
    inc(i);
    while ((not Found) and (j < y-1)) do begin
      inc(j);
      while ((not Found) and (k < z-1)) do begin
        inc(k);
        Found := Condition(i, j, k);
      end;
    end;
  end;
  if not Found then begin
    Error;
    Exit;
  end;
  // do some stuff using the values of i, j and/or k
end;

Geen break nodig, maar je moet wel zorgen dat je i, j en k steeds op 1 waarde lager begint dan je eigenlijk wilt, en dan als eerste binnen de while-loop die waarde ophoogt. Anders worden i, j en k alsnog 1 hoger dan je eigenlijk wilt. Maar al met al een vrij elegante oplossing IMO.

[ Voor 3% gewijzigd door Verwijderd op 31-05-2006 22:37 ]

[MSalters]

igmar schreef op woensdag 31 mei 2006 @ 08:39:
[...]
Hoezo is dat relevant ? In mijn voorbeeld modificeer je nog steeds 2 keer dezelfde variabele zonder een sequence point, die pas eindigd na de ; Da's undefined behaviour, da's mijn punt, en dat ben ik wel eens tegengekomen in functieaanroepen.
...
Bovendien leveren pure berekeningen als (2*b+1) geen sideeffects op, en staan ze dus sowieso los van sequence points.

ik geloof dat we 't met elkaar eens zijn. Ik dacht dat je probeerde uit te leggen waar de "regel" vandaan kwam die drukaf(2*b+1) afkeurde, maar we zijn het dus eens dat dat niets met sequence points te maken heeft.

[MSalters]

Ivo schreef op woensdag 31 mei 2006 @ 11:11:
[...]

code:

a[i] = i++;

Dit levert helemaal geen ongedefinieerd gedrag op. Dit is equivalent aan:

code:

a[i] = i; i++;

In Java wel, maar niet in C. D'r is ergens een code=c tag weggevallen, maar het stond wel expliciet in de uitleg erbij dat het om C ging.

[Ivo]

Ik dacht dat dit in C ook zo was. Blijkbaar is dit niet zo.

[.oisyn]

Ik denk dat dat komt omdat er het idee te ronde gaat dat de post-fix increment (en decrement) betekent dat hij uitgevoerd wordt na het huidige statement. Dat is niet zo. i++ betekent: verhoog i, maar retourneer de vorige waarde. In C++ zou de functie-implementatie er zo uitzien:

C++:

int increment(int & var)
{
    int oldValue = var;
    var += 1;
    return oldValue;
}

De statement a[i] = i++ kun je dan zo lezen:

C++:

a[i] = increment(i);

De vraag is dan of de increment functie wordt uitgevoerd vóórdat a[i] wordt geevalueerd. En dat is nou juist niet gedefinieerd in C en C++ (maar wel in Java en C#. In PHP vast ook niet maar daar is het waarschijnlijk ook niet gedefinieerd dat het ongedefinieerd is, if you catch my drift )

[Verwijderd]

hamsteggot schreef op maandag 29 mei 2006 @ 10:49:
Wat is in jullie ogen een goede balans tussen goede code schrijven en het voor de hobby ook nog een beetje snel afhebben?

Een goede belans is goede code, punt. Zonder compromis. Die is immers sneller af doordat je minder tijd kwijt bent met achteraf fouten opsporen en verbeteren. Het is bekend dat bugs oplossen achteraf (vrijwel) altijd duurder is, dan in een eerder stadium beter werk afleveren. Investeer dus wat tijd om goede code te schrijven. Hoe minder tijd er is om iets te maken, hoe belangrijker dat is!

Belangrijke beperking in deze discussie is wel dat het een consequente keuze moet zijn

Kan misschien niet als je het als eis stelt voor deze discussie maar daar ben ik het niet mee eens. Er zijn alleen maar guidelines en geen regels. Er is bijna altijd wel een uitzondering te verzinnen waarin het alternatief beter werkt. Tuurlijk, als je twijfelt, houdt je dan aan de guidelines want er is natuurlijk wel een reden voor dat die bestaan.

Mijn enige 'regel' is dat je altijd je gezonde verstand moet blijven gebruiken. Helaas lijkt het er op dat er veel mensen zijn die dat niet (of te weinig) hebben

Een heel andere manier om goede code af te leveren (thinking out of the box) kan bijvoorbeeld ook iets als Pair Programming zijn. Je zit dan met zijn tweeen achter een machine en schrijft samen de code. De praktijk wijst uit dat dit in veel gevallen heel goed werkt om de kwaliteit van code te verbeteren zonder dat het veel tijd kost (en door de betere kwaliteit dus juist veel tijd bespaart!)

Het is eigenlijk een vorm van continu code reviewen. En waar je normaal met 1 persoon een fout maakt als je even niet oplet, is er bij Pair Programming vrijwel altijd die ander die dan wel zit op te letten. Bovendien leer je van elkaar en vul je elkaar's kennis aan.

Ik heb op eigen initiatief een korte tijd kennis kunnen maken met Pair Programming, maar 'helaas' zit ik nu bij een heel leuk maar kleiner bedrijf waar ik (niet lang meer) de enige echte software developer ben en ik mis af en toe de feedback wel (ondanks dat ik natuurlijk een geweldig programmeur ben )

Silver bullets bestaan niet, maar helaas geloven veel mensen daar wel in - wat blijkt uit iedere nieuwe taal die weer gehyped wordt, en niet waar maakt wat er van verwacht wordt. (Pair Programming is dus ook geen Silver bullet, maar het kan wel helpen)

En probeer af en toe ook een beetje defensief te programmeren. Denk niet te snel dat je bepaalde 'trucs' door-en-door kent en dus altijd foutloos gebruikt. En probeer vooral in de code niet te laten zien hoe slim je bent, dat levert waarschijnlijk de ergste code op...

offtopic:
Mijn 'record' is een stuk C code van ongeveer 1000 regels terug te brengen tot minder dan de helft waarbij de leesbaarheid flink toenam, de executietijd minstens een factor 100 lager was (~ 1 minuut naar <1 seconde) - en het ergste was dat volgens de requirements dat stuk code 'geoptimaliseerd' had moeten zijn omdat de executietijd toch wel belangrijk was. Waarom was die code zo slecht? Omdat iemand zich strikt aan een set coding conventies / regels gehouden had die (vooral voor deze context) slecht gekozen waren.

[ronaldmathies]

Janoz schreef op woensdag 31 mei 2006 @ 11:14:

Bij realtime is het van belang dat je exacte garanties kunt geven wanneer iets gebeurt en wanneer wordt aangegeven dat dit niet gaat lukken. De specificaties van de VM staan dit niet toe. Er zijn wel wegen omheen (door een nieuwe VM te schrijven die extra garanties biedt), maar dan blijft nog wel staan dat java niet de geschikte taal is voor realtime toepassingen.

Even tussendoor, hiervoor is de Java Realtime Specification opgesteld, waarin het wel toegelaten wordt om realtime te kunnen werken.:

http://www.onjava.com/pub...me-java-introduction.html

[crisp]

.oisyn schreef op woensdag 31 mei 2006 @ 23:13:
[...]
De vraag is dan of de increment functie wordt uitgevoerd vóórdat a[i] wordt geevalueerd. En dat is nou juist niet gedefinieerd in C en C++ (maar wel in Java en C#. In PHP vast ook niet maar daar is het waarschijnlijk ook niet gedefinieerd dat het ongedefinieerd is, if you catch my drift )

In PHP is gedefinieerd dat assignments right to left geevalueerd worden; dus in een geval als:

PHP:

$foo = increment($bar);

wordt eerst de functie uitgevoerd en de returnvalue toegekent aan $foo

[.oisyn]

Euh, bij je voorbeeld doet de order van evaluation er juist niet toe. Bovendien doet PHP helemaal niet wat jij zegt:

PHP:

function increment(&$var)
{
    $old = $var;
    ++$var;
    return $old;
}

$a = array(-1, -1, -1);
$i = 0;
$a[$i] = increment($i);

print_r($a);

output: array(0, -1, -1).
Als increment werd aangeroepen vóórdat $a[$i] geevalueerd werd, zou hij schrijven naar element 1. Hij schrijft echter naar element 0, omdat hij $a[$i] al evalueerd voordat hij increment aanroept. (PHP 4.4.2)

[crisp]

hmmz, my bad; ik dacht dat het betekende dat increment($i) eerst geeavuleerd zou worden, vervolgens $a[$i] en dat dan pas de assignment plaats zou vinden; het lijkt echter andersom te zijn...

[.oisyn]

Nou ja dat zou het idd moeten betekenen, maar blijkbaar is het dus niet zo

.edit: heb het even opgezocht, de order van evaluatie staat niet expliciet in de documentatie. Dit wel:

Left associativity means that the expression is evaluated from left to right, right associativity means the opposite.

Maar dat heeft met assocativiteit te maken, niet met evaluatie van de expressies. Right-associative wil zeggen dat a = b = c wordt geparsed als a = (b = c). Parse order staat los van de volgorde van evaluaties (in C# en Java is de = uiteraard ook right-associative, maar beide talen evalueren altijd van links naar rechts - zal me niets verbazen als dat in PHP ook zo is, maar het is gewoon niet gedefinieerd dus daar kun je imho ook niet op vertrouwen)

[ Voor 99% gewijzigd door .oisyn op 01-06-2006 13:17 ]

[Verwijderd]

crisp schreef op donderdag 01 juni 2006 @ 12:56:
hmmz, my bad; ik dacht dat het betekende dat increment($i) eerst geeavuleerd zou worden, vervolgens $a[$i] en dat dan pas de assignment plaats zou vinden; het lijkt echter andersom te zijn...

Door defensief te programmeren vermijdt je dit soort constructies omdat het niet impliciet duidelijk is wat er gebeurt (en niet zozeer omdat een coding standard je vertelt dat het niet mag). En als je denkt te weten wat er gebeurt, dan komt er een andere taal die er op lijkt maar het toch weer anders doet. Of er komt een andere programmeur die het niet weet en een bug veroorzaakt door wat hij denkt dat een bug is te verhelpen waardoor het daarna fout gaat

[.oisyn]

Niemand beweert het tegendeel, het ging er gewoon even om of PHP het idd definieerde of niet.

[MSalters]

.oisyn schreef op woensdag 31 mei 2006 @ 23:13:

C++:

int increment(int & var)
{
    int oldValue = var;
    var += 1;
    return oldValue;
}

De statement a[i] = i++ kun je dan zo lezen:

C++:

a[i] = increment(i);

De vraag is dan of de increment functie wordt uitgevoerd vóórdat a[i] wordt geevalueerd.

Erger. De opties zijn niet alleen vóór of na, maar ook tegelijkertijd (kan op Itanium e.d.), helemaal niet, onvoorspelbaar (cache race conditie), of nog vreemder gedrag.

[hamsteg]

Verwijderd schreef op woensdag 31 mei 2006 @ 23:33:
Mijn enige 'regel' is dat je altijd je gezonde verstand moet blijven gebruiken. Helaas lijkt het er op dat er veel mensen zijn die dat niet (of te weinig) hebben

Een heel andere manier om goede code af te leveren (thinking out of the box) kan bijvoorbeeld ook iets als Pair Programming zijn. Je zit dan met zijn tweeen achter een machine en schrijft samen de code.

Deze regel geldt boven alles. Wij programmeren altijd met de guidlines in de hand maar als we daarop afwijken zetten we het er gewoon in commentaar bij ;-) Zolang je maar bewust bent dat je afwijkt is het ok.

Pair programming, of extremer: dual programming. Twee teams werken onafhankelijk van elkaar en schrijven dezelfde code. Als de twee programma's lopen zou je verwachten dat ze niet dezelfde fout maken ... not. Boeing heeft dit ooit eens geprobeerd met twee backup systemen in hun vliegtuigen. Achteraf gezien bleken dezelfde functionele fouten in alle drie de systemen te zitten. De manier van denken blijkt zo in ons geprent te zitten dat we dezelfde fouten maken

Reviews hebben wat mij betreft een absolute waarde. De hele dag bij elkaar op schoot zitten heeft minder zin omdat je elkaar dan ook mee neemt in foute denkpatronen. Elkaars code grondig reviewen is zeer effectief! Veel programmeerfouten en een setje aan functionele fouten worden er dan uitgehaald.

offtopic:
Schroeven vastdraaien met een hamer is mij ook nog nooit gelukt Juiste guidlines voor de juiste toepassing is zeer belangrijk.

[Verwijderd]

hamsteggot schreef op vrijdag 02 juni 2006 @ 20:46:
Boeing heeft dit ooit eens geprobeerd met twee backup systemen in hun vliegtuigen. Achteraf gezien bleken dezelfde functionele fouten in alle drie de systemen te zitten. De manier van denken blijkt zo in ons geprent te zitten dat we dezelfde fouten maken

Volgens mij wordt deze strategie nog steeds toegepast bij Airbus, waarbij twee onafhankelijke systemen elkaar controleren en instructies pas worden doorgegeven als beide systemen hetzelfde resultaat geven. De ene draait dan op Intel en de andere op Motorola om zodoende eventuele fouten in de processor af te vangen. Dus het is een soort PC/Mac battle maar dan in de lucht Weet niet of ze dit nog zo doen, het artikel is jaren oud.

[Verwijderd]

Tja, pair programming...
Mijn ervaring is dat dat prima werkt wanneer je nieuwe dingen ontwerpt, 2 personen kunnen dan meer bedenken (en van elkaar controleren) dan 1 persoon kan codekloppen.
Maar bij de normale dingen (bestaande code aanpassen of op punten uitbreiden) is m.i. een goede peer review een stuk zinvoller en efficienter.

Neemt niet weg dat ik als programmeur pair programming erg prettig vind om te doen, omdat de uitwisseling van ideeen dan veel directer is dan bij een peer review achteraf.

[Verwijderd]

hamsteggot schreef op vrijdag 02 juni 2006 @ 20:46:
Pair programming, of extremer: dual programming. [...]

Maar dual programming zoals je het noemt zal in de praktijk als normaal ontwikkelwerk door individuen gedaan worden. Plus natuurlijk dat beide teams afhankelijk zijn van dezelfde (al dan niet) vage requirements van buitenaf waardoor ze dezelfde fouten maken. Dat zal niet veranderen welke manier van werken je ook kiest. Pair Programming is echt iets heel anders dan dual programming.

Alhoewel het misschien contra-intuitief lijkt, is er genoeg materiaal te vinden wat laat zien dat Pair Programming echt werkt* (natuurlijk niet in alle gevallen, maar wel veel en mits het goed opgezet is). Natuurlijk kunnen twee mensen samen tegelijk dezelfde fout maken, maar het is veel minder waarschijnlijk dan dat twee mensen los van elkaar ieder een eigen fout maken. Je kunt het een beetje als een AND-functie zien Als een programmeur wel of geen fout kan maken, krijg je de volgende waarheidstabel (P1 en P2 zijn twee programmeurs, Pair is de 'and' functie voor Pair Programming):

P1	P2	Pair
geen fout	geen fout	geen fout
geen fout	wel fout	geen fout
wel fout	geen fout	geen fout
wel fout	wel fout	wel fout

Als de programmeurs los van elkaar werken en P1 module 1 schrijft en P2 module 2, heb je totaal 4 fouten in de code zitten. Als je echter met Pair Programming werkt, zullen de programmeurs bij rij twee en drie elkaars fouten zien, en dus direct oplossen. Er wordt dan dus maar 1 fout gemaakt bij het schrijven van module 1, en weer 1 bij het schrijven van module 2. Het totaal aantal fouten is dus gehalveerd**.

Reviews hebben wat mij betreft een absolute waarde.

Het nadeel van traditioneel code reviewen is dat dit achteraf pas gebeurt. De programmeur zal dan (vaak) zijn harde werk willen verdedigen en niet geneigd zijn snel iets aan te passen. Bovendien is er tegen die tijd vaak al (deels) getest en wordt het aanpassen van de code in dat stadium als risico (en zinloos extra werk) beschouwd waardoor er weinig van de (zinvolle!) opmerkingen meegenomen wordt.

Bij Pair Programmen review je elkaar's werk live, en kan er dus direct ingegrepen worden als dat nodig is. Overigens wil dat niet zeggen dat de code helemaal niet meer gereviewd hoeft te worden - dat kan immers nog steeds zinvol zijn voor opmerkingen van anderen, en een blik van een afstand. Ik ben het dus wel met je eens dat code reviews heel zinvol zijn - zeker als er weinig andere vormen van controle zijn!

* Zoals bijna altijd zijn er ook gegevens die laten zien dat het niet werkt, dus ik zou zeggen: probeer het eens een tijdje uit op een project en kijk wat je er van vindt (ik heb het gedaan, en ik ben overtuigd ). Een goed boek om mee te beginnen is Pair Programming Illuminated van Laurie Williams.

** Deze cijfers zijn maar een voorbeeld om het principe uit te leggen. In werkelijkheid is er geen factor 2 verlaging van fouten. Onderzoek (PDF) laat zien dat Pair Programming 15% meer tijd kost, maar ook 15% minder fouten oplevert. Aangezien de fouten echter in een eerder stadium worden verholpen dan anders, levert dit uiteindelijk een fikse besparing op.

[Woy]

Verwijderd schreef op zaterdag 03 juni 2006 @ 00:13:
[...]

Volgens mij wordt deze strategie nog steeds toegepast bij Airbus, waarbij twee onafhankelijke systemen elkaar controleren en instructies pas worden doorgegeven als beide systemen hetzelfde resultaat geven. De ene draait dan op Intel en de andere op Motorola om zodoende eventuele fouten in de processor af te vangen. Dus het is een soort PC/Mac battle maar dan in de lucht Weet niet of ze dit nog zo doen, het artikel is jaren oud.

Sterker nog, dit wordt nog steeds gebruikt in meerder militaire systemen. In bijvoorbeeld een F16 zijn systemen meerdere malen uitgevoerd en wordt door middel van een soort van Vote systeem bepaald wat er gebeurd. Hoe belangrijker een systeem is hoe vaker het uitgevoerd is. Er zijn zelfs systemen waar 7 aparte systemen een vote uit brengen.

[Woy]

Verwijderd schreef op zaterdag 03 juni 2006 @ 00:36:
[...]

P1	P2	Pair
geen fout	geen fout	geen fout
geen fout	wel fout	geen fout
wel fout	geen fout	geen fout
wel fout	wel fout	wel fout

Maar als je 2 verschillende antwoorden hebt hoe kun je dan bepalen wat de goede keuze is om te maken. Stel je hebt een splitsing en de ene zegt links af en de ander rechts af. Je weet dan nooit wat de beste keuze is. Je hebt daarvoor altijd een oneven aantal nodig of je moet van te voren weten welke keuze je voorang geeft boven de andere.

[Verwijderd]

rwb schreef op zaterdag 03 juni 2006 @ 01:40:
Maar als je 2 verschillende antwoorden hebt hoe kun je dan bepalen wat de goede keuze is om te maken.

Mensen komen daar samen wel uit. Het is dan niet anders dan een normale situatie als een test faalt: is de test code fout, of de echte code?

Maar wat betreft machines heb je gelijk. Het enige dat je met twee kunt doen is een alarm geven als er iets niet klopt, en de mens laten beslissen (als daar tijd voor is, en mogelijkheden toe zijn). Als dat niet kan moet er een voorrang krijgen, en dat maakt natuurlijk de tweede overbodig (tenzij er een slim algoritme is om te kiezen wie gelijk heeft, maar daar kan ook weer iets mee fout gaan...)

[flowerp]

Verwijderd schreef op zaterdag 03 juni 2006 @ 00:36:
Het nadeel van traditioneel code reviewen is dat dit achteraf pas gebeurt. De programmeur zal dan (vaak) zijn harde werk willen verdedigen en niet geneigd zijn snel iets aan te passen.

In het verlengde hiervan: in de praktijk worden aantekeningen in code reviews vaak gebruikt om meningen door te drukken; iets is niet perse goed of fout, maar programmeur A heeft een groot ego en vind dat alles op manier A moet, maar programmeur B heeft een nog veel groter ego en vind dat alles op B moet.

Pas nog meegemaakt tijdens een code review. De ene persoon is zwaar tegen het gebruik van singleton patterns in code en streep elk gebruik hiervan meteen als fout aan. De andere echter vind het juist de oplossing voor elk probleem en pas het zeer vaak toe. Wat gebeurd er dan in een review? Een uur lange discussie over singletons, en aan het eind van de dag is de code nog steeds hetzelfde.

Persoonlijk zou ik wel wat zien in pair programming, maar ik zou 't niet echt kunnen. Als je samen achter de computer zit heb je altijd zo'n drang om een dialoog open te houden. Dingen moeten 'meteen' gedaan worden want alles 'duurt te lang'. Als ik in m'n eentje ben staar ik eens 5 minuten naar buiten, of step ik eens rustig door wat source heen. Als er iemand naast je zit (wat we soms wel eens doen) doe je dat niet, want je wilt de ander niet ophouden.

Wat ik wel belangrijk vind is dat je een soort code roulatie doet, waarbij verschillende programmeurs om en om aan een zelfde 'module' werken. Wij werken op dit moment aan een systeem dat uit verschillende onderdelen bestaat (welke groter systeem niet). Het punt is dat voor elk onderdeel eigenlijk 1 programmeur verandwoordelijk is. Zo hebben we een data-import en die hele module is het domein van Eric. Een ander onderdeel is een tijd planner en dat hele stuk, van GUI via business logic tot DB tables 'is van' Marco. Dit gaat eigenlijk zo door voor alle onderdelen.

Het probleem is dat er nu eilandjes ontstaan, omdat elke programmeur vind dat hij/zij het het beste weet en elke keer het wiel opnieuw gaat uitvinden. Zo had Eric voor de data-import bijvoorbeeld een serie filtering classes door en bouwde daar ad-hoc maar even een eigen mini frameworkje voor. Bestaat uit tig spannend klinkende namen voor classes en packages, maar... alleen Eric's code gebruikt dit. Nu zag ik laatst dat ook Marco -ook- aan data import doet; namelijk de user wordt de mogelijkheid gebode om complete schema's te uploaden, en daar voor heeft ie dan dan een UniversalCSVToXMLParser voor geschreven. Eric had echter al een BaseCSVImporter.

Aan de ene kant zou je zeggen dat dit goed is. De aparte onderdelen van onze app hebben bijna 0% dependencies op elkaar, maar de code duplicatie is ook zeer groot. Opzich is er wel de wil om van elkaars code gebruik te maken, maar zodra Eric een functie mist in Marco's code gaat ie gewoon zelf een nieuw vervangend systeem maken wat die functie wel heeft.

Als je de code rouleerd dan heb je imho meer het gevoel dat het ook 'jou' code is.

[hamsteg]

Verwijderd schreef op zaterdag 03 juni 2006 @ 00:36:
[...]
Het nadeel van traditioneel code reviewen is dat dit achteraf pas gebeurt. De programmeur zal dan (vaak) zijn harde werk willen verdedigen en niet geneigd zijn snel iets aan te passen.

Dat hangt een beetje samen denk ik met je projectenteam en hoe je projectleider er mee om gaat. De eerste review is nooit leuk (echt de eerste keer is verschikkelijk) maar als de rest van het team dat samen met jou ook oppakt ontstaat er een teamgeest en valt de verdediging snel weg. Als je met elkaar eerlijk bent over het doel moet dit geen probleem geven. Maar zie ook volgende opmerking.

Bij Pair Programmen review je elkaar's werk live, en kan er dus direct ingegrepen worden als dat nodig is. Overigens wil dat niet zeggen dat de code helemaal niet meer gereviewd hoeft te worden - dat kan immers nog steeds zinvol zijn voor opmerkingen van anderen, en een blik van een afstand. Ik ben het dus wel met je eens dat code reviews heel zinvol zijn - zeker als er weinig andere vormen van controle zijn!

Persoonlijk vind ik dit te laat. Coderen is het uitontwikkelen van een design. Dat je in de design fase met elkaar om tafel zit lijkt mij een must. Vaak heeft een architect of senior programmeur het globale overall beeld en kent de programmeur de grenzen van gekozen hard/software. Daarom maak je als programmeur een detailed design waarbij critische elementen in pseudo code worden uitgewerkt. Dit wordt gereviewed. Het coderen zelf is de kunst en ervaring van omzetten van functionaliteit naar bits en bytes.

In mijn ervaring is het efficienter om zelf te coderen en daarna reviews te doen ... met 1 uitzondering: In een team met teamgeest zal een programmeur sneller geneigd zijn even iemand te vragen eerder al na een stukje code te kijken of gewoon mee te denken als de programmeur al weet dat dat deel critisch is. Maar omdat het grootste deel van de code gewoon uitcoderen van een design is, zie ik 100% pair coding niet zitten. Bij onze teams zal dat eerder een percentage onder de 5% zijn. Dat is 95% winst in een tweede programmeur kwa tijd en dat verlies je normaal gesproken niet met de twee reviews (design en code).

Let wel pair programming voor critische delen wordt ook door mij 100% aangeraden!

[Verwijderd]

flowerp schreef op zondag 04 juni 2006 @ 14:03:
Als je samen achter de computer zit heb je altijd zo'n drang om een dialoog open te houden. Dingen moeten 'meteen' gedaan worden want alles 'duurt te lang'. Als ik in m'n eentje ben staar ik eens 5 minuten naar buiten, of step ik eens rustig door wat source heen. Als er iemand naast je zit (wat we soms wel eens doen) doe je dat niet, want je wilt de ander niet ophouden.

Dit maakt het werk wel een stuk efficienter . Het is ook meteen het gevaar, want je bent veel intensiever bezig, en moet dus bewust af en toe pauze houden. Normaal betrap ik me er ook vaak op dat ik eigenlijk alleen voor de lunch pauzeer, maar met Pair Programming is dat niet vol te houden en moet je echt (bijvoorbeeld) ieder uur minimaal 5 minuten 'afkoelen'. Even koffie/thee halen, gewoon wat rondlopen, of bijvoorbeeld even je email checken.

hamsteggot schreef op zondag 04 juni 2006 @ 14:09:
In mijn ervaring is het efficienter om zelf te coderen en daarna reviews te doen ...

Ik denk dat het een (beetje) verschil van definitie is. Voor mij is 'programmeren' het hele proces dat ontwerp, implementatie en testen omvat. Het is bijna nooit zo dat ik een design zie dat zo ver uitgewerkt is dat de implementatie triviaal is. Juist bij de implementatie kom ik vaak dingen tegen die eerder over het hoofd gezien waren, of die beter kunnen dan gedacht.

Natuurlijk gaat het bij Pair Programming niet om alleen de implementatie samen te doen als er een 'perfect' design klaar ligt. Je moet het in meer of mindere mate in alle stadia toepassen, en voor echt triviale dingen (wat je 'uitcoderen' noemt veronderstel ik) inderdaad liever niet - want dan levert het te weinig op. Wellicht is een naam die men beter begrijpt ook 'Pair Working', om verwarring te voorkomen.

Anderhalf jaar geleden heb ik een pilot opgestart op mijn toenmalige werkplek, waarbij we met drie man een deelproject op deze manier aangepakt hebben. We wisten dat het niet 100% van de tijd nuttig zou zijn, maar om een goed beeld te kunnen vormen hebben we activiteiten waarvan we niet zeker wisten of het positief of negatief zou uitpakken wel met Pair Programming gedaan. Daardoor konden we achteraf beter inzien hoe het werkt. Uiteindelijk is het ons allemaal heel goed bevallen. We hebben geen harde cijfers kunnen verzamelen (er is natuurlijk nooit een situatie om goed mee te vergelijken) maar onze indruk was wel:
* Plezierige manier van werken
* Betere code (betere designkeuzes, minder fouten)
* Voor triviale code kost het meer tijd
* Je leert van elkaar (kennisspreiding, risicoverlaging)
* Meer gefocusseerd op het werk

Bij de pilot was kennisspreiding ook een belangrijke wens (vooral om te voorkomen dat bij uitval van personeel bepaalde kennis verloren zou gaan), maar het laatste voordeel was deels onverwacht. Bij Pair Programming ziet men dat je bezig bent en onderbreekt men je veel minder vaak voor triviale dingen. Dit in tegenstelling tot wanneer je alleen (maar geconcentreerd) zit te werken, dan ziet men dat niet en wordt je gewoon van alles gevraagd, en ben je steeds je 'flow' kwijt...

Maar goed, nu heb ik er wel genoeg over gezegd denk ik. Degenen die het interessant vinden moeten het maar eens uitproberen Slotopmerking: een goed ontwikkelteam heeft een hele serie 'tools' ter beschikking, past die op de juiste momenten toe en begrijpt dat iedere situatie uniek is en zijn eigen aanpassingen nodig heeft.