Verschillende programmeerstijlen; voor- en nadelen

[JKVA]

BalusC schreef op maandag 29 januari 2007 @ 09:56:
...

Ik zit nog te twijfelen tussen de eerste en derde. Die tweede vind ik heel lelijk, vooral omdat je een while gebruikt met alle gevolgen van dien. (zoals wanneer ze null zijn, het is niet overzichtelijk, want een while duidt op iteraties vind ik...)

Er is eventueel nog een vierde optie, namelijk de derde, maar dan met else ifs zodat je niet per se direct hoeft te returnen. Of het mooi is, hangt denk ik van de situatie af. In een methode met 2 variabelen vind ik een tmp variabele overkill, maar wanneer het groeit, kan het handig zijn, ook met debuggen.

[Verwijderd]

BalusC schreef op maandag 29 januari 2007 @ 09:56:
Hoe gaan jullie om met een combinatie van meerdere selectie statementen en meerdere return plaatsen binnen een methode? De een zegt dat geneste selectie statementen zuigen en dat de ander zegt dat meerdere return plaatsen binnen een methode onoverzichtelijk is.

...

Een combinatie van 1 + 3. Eigenlijk dus geen van al jouw voorbeelden. Er wordt teveel verschillende logica in 1 methode gebundeld op deze manier. Daarnaast dient een methode eigenlijk maar 1 entry en exit point te hebben.

[BalusC]

Er is eventueel nog een vierde optie, namelijk de derde, maar dan met else ifs zodat je niet per se direct hoeft te returnen.

Maar die moeten dan weer genest worden.

Een combinatie van 1 + 3.

Laat eens zien

[mithras]

BalusC schreef op maandag 29 januari 2007 @ 10:47:
[...]
Maar die moeten dan weer genest worden.
[...]
Laat eens zien

Bedoelen ze (om zo maar één exit point te hebben) zoiets:

Java:

public Object doSomething() {
    if (!exp1) {
        // code7
        returnValue = value4;
    }

    // code1

    if (!exp2) {
        // code6
        returnValue = value3;
    }

    // code2

    if (!exp3) {
        // code5
        returnValue = value2;
    }else {
        // code4
        returnValue = value1;
    }

    // code 3

    return returnValue;
}

[Verwijderd]

BalusC schreef op maandag 29 januari 2007 @ 09:56:
Hoe gaan jullie om met een combinatie van meerdere selectie statementen en meerdere return plaatsen binnen een methode? De een zegt dat geneste selectie statementen zuigen en dat de ander zegt dat meerdere return plaatsen binnen een methode onoverzichtelijk is.

Ik zoek dan eerder naar een oplossing met een map of list of iets dergelijks. Omdat je dan zeer overzichtelijk uit een lus kan breken, hetgeen wat je doorgaans wilt met een switch-case...

[merauder]

code:

if (vergelijking==VoorbeeldVoorwaarde)

     {
             cout <<  vooruit << endl;
     }   

else 
    {
            cout <<  achteruit << endl;
    }

Rare stijl maar weinig stukken code per regel, verder gebruik ik bij If/Else constructies Tabs om aan te geven op welk niveau de code verweven is. Is handig bij een If/Else constructie BINNEN een If/Else constructie.

[Mastermind]

Ik programmeer op deze manier. Ik mag graag compact programmeren, omdat je dan niet zoveel hoeft te scrollen en een goed overzicht hebt over de code.

Een gedeelte van een programma dat ik heb geschreven, toont bijv. aan hoe handig turnaries zijn:

C#:

string ExternContractnr = factuurEnt.TestCurrentFieldValueForNull(FactuurFieldIndex.ExternContractnr) ? "" : factuurEnt.ExternContractnr.Trim();
while (reportNameExists)
{
      achtervoegselStr = (achtervoegsel++).ToString().PadLeft(2, '0');
      TheNextFileName = ExternContractnr.IndexOfAny(Path.GetInvalidFileNameChars()) > 0 || ExternContractnr == ""
       ? aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses.pdf"
       : aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses " + ExternContractnr + ".pdf";
                
       testFilename1 = Path.Combine(finaldir1, TheNextFileName);
       if (alsoTheEditMap)
        {
             testFilename2 = Path.Combine(finaldir2, TheNextFileName);
             testFilename3 = Path.Combine(finaldir3, TheNextFileName);
        }

         reportNameExists = (File.Exists(testFilename1) ||  ((alsoTheEditMap && File.Exists(testFilename2)) || (alsoTheEditMap && File.Exists(testFilename3))));
}

[.oisyn]

Je moet wel scrollen, alleen links/rechts ipv onder/boven. En je identing is nou ook niet echt bepaald consistent. Je naamgeving ook niet trouwens.

[Creepy]

Handig? Ik weet hoe het werkt maar moet je regel code toch een paar keer nakijken om nu precies te zien wat het doet. Omdat je het gebruikt in een toekenning moet je veel specifieker gaan zoeken naar waar de conditie zit, terwijl je dat met een if directer / sneller zou zien.

[Verwijderd]

Mastermind schreef op dinsdag 30 januari 2007 @ 12:46:
Ik programmeer op deze manier. Ik mag graag compact programmeren, omdat je dan niet zoveel hoeft te scrollen en een goed overzicht hebt over de code.

Een gedeelte van een programma dat ik heb geschreven, toont bijv. aan hoe handig turnaries zijn:

C#:

string ExternContractnr = factuurEnt.TestCurrentFieldValueForNull(FactuurFieldIndex.ExternContractnr) ? "" : factuurEnt.ExternContractnr.Trim();
while (reportNameExists)
{
      achtervoegselStr = (achtervoegsel++).ToString().PadLeft(2, '0');
      TheNextFileName = ExternContractnr.IndexOfAny(Path.GetInvalidFileNameChars()) > 0 || ExternContractnr == ""
       ? aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses.pdf"
       : aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses " + ExternContractnr + ".pdf";
                
       testFilename1 = Path.Combine(finaldir1, TheNextFileName);
       if (alsoTheEditMap)
        {
             testFilename2 = Path.Combine(finaldir2, TheNextFileName);
             testFilename3 = Path.Combine(finaldir3, TheNextFileName);
        }

         reportNameExists = (File.Exists(testFilename1) ||  ((alsoTheEditMap && File.Exists(testFilename2)) || (alsoTheEditMap && File.Exists(testFilename3))));
}

Volledig onleesbaar is deze code wat mij betreft.

[BalusC]

Hmja, ik scroll liever verticaal dan horizontaal De conditional statement (exp ? stmt1 : stmt2) vermijd ik ook liever in deze context. Dan gebruik ik liever een overzichtelijke if else statement. De conditional statementen gebruik ik eerder bij de zgn. boolean toggles die in 1 regel passen.

Java:

String string = booleanValue ? "stringValue1" : "stringValue2";

[merauder]

Verticaal scrollen ben ik ook niet zo weg van, een simpele druk op 'page-up/page-down' + het scrollwielletje van mijn muis werken toch beter.

[Mastermind]

Ja je moet nu verticaal scrollen omdat het zo'n klein venstertje is. Er zit overigens een pijltje linksboven om het breed te maken.

Op een groot scherm is het zeer overzichtelijk en kan ik in 1 oogopslag zien wat er gebeurt. Superhandig! Ik gebruik zelf camelcasing.

De ident staat hier niet goed omdat dat codeschermpje geen tabs goed weergeeft.

[ Voor 13% gewijzigd door Mastermind op 30-01-2007 13:17 ]

[.oisyn]

merauder schreef op dinsdag 30 januari 2007 @ 13:09:
Verticaal horizontaal scrollen ben ik ook niet zo weg van, een simpele druk op 'page-up/page-down' + het scrollwielletje van mijn muis werken toch beter.

Idd.

Mastermind schreef op dinsdag 30 januari 2007 @ 13:11:
Ja je moet nu verticaal horizontaal scrollen omdat het zo'n klein venstertje is. Er zit overigens een pijltje linksboven om het breed te maken.

Nee, mijn punt is dat je met dergelijke code al snel horizontaal moet scrollen. Ik heb hier een 1920x1440 scherm, en zelfs dan breek ik al eerder af dan jij doet. Da's ook handig als je twee schermen naast elkaar hebt (bijvoorbeeld header/source in c++, of in de gebruikelijke merge tool van je source control systeem).

Op een groot scherm is het zeer overzichtelijk en kan ik in 1 oogopslag zien wat er gebeurt. Superhandig! Ik gebruik zelf camelcasing.

waarom dan af en toe namen beginnen met een hoofdletter?

En je indenting heb je ook nog steeds niet beargumenteerd

[Verwijderd]

merauder schreef op dinsdag 30 januari 2007 @ 12:08:

C++:

 
if (vergelijking==VoorbeeldVoorwaarde)

     {
             cout <<  vooruit << endl;
     }   

else 
    {
            cout <<  achteruit << endl;
    }

Nadeel vind ik hiervan dat je 1) horizontaal een extra indentatie level toevoegt met geen toegevoegde waarde en 2) dat je accolades extra verticale ruimte innemen. Zelf doe ik altijd dit:

C++:

if (vergelijking==VoorbeeldVoorwaarde) {
    cout <<  vooruit << endl;
} else {
    cout <<  achteruit << endl;
}

Vind ik overzichtelijker en compacter. Maar ik weet dat lang niet iedereen het daarmee eens is...

Ik heb trouwens ook wel een het volgende gezien (voor mensen die klagen over het niet kunnen vinden van begin en eind van een blok): puntkomma's vooraan de regel in plaats van achteraan.

Delphi:

while test1 do begin
    while test2 do begin
    ;    func1
    ;    func2
    ;    if blaat then begin
         ;    doIets
         ;    doNogIets
    ;    end
;   break
;   end
end
}

Voorwaarde om dit te kunnen doen is dat de taal het weglaten van de puntkomma voor het eind van een blok toestaat. Ik weet niet of dit in alle talen het geval is...

[BalusC]

Trouwens, hoe denken jullie over het toepassen van de moedertaal in de code? Ik zie best wel veel lappen code met Nederlands/Engels gemixt, wat ik persoonlijk best wel ranzig vind Op buitenlandse forums zie ik ook lappen code met termen in het Spaans, Duits en zelfs Chinees

Voor mijn werk moet ik het Nederlandse taal helaas wel toepassen in de namen van de klassen, methoden en variabelen. Maar voor eigen projectjes zou ik het 100% in het Engels houden. Niet alleen voor de uniformiteit (de sleutelwoorden en operatoren van de codetaal zijn immers ook in het Engels), maar ook voor een betere (internationale) uitwisselbaarheid

[ Voor 6% gewijzigd door BalusC op 30-01-2007 13:43 ]

[Grijze Vos]

Dat is een betrekkelijk normale stijl voor TU/e'ers wat je daar post.

[.oisyn]

BalusC schreef op dinsdag 30 januari 2007 @ 13:42:
Voor mijn werk moet ik het Nederlandse taal helaas wel toepassen in de namen van de klassen, methoden en variabelen.

OMG . Ik vind dat er zo onprofessioneel uitzien altijd. Wij werken met amerikanen en australiers, dus een andere taal dan Engels is sowieso al geen optie, maar zelfs zonder die situatie zouden we hier in het Engels programmeren

[Grijze Vos]

BalusC schreef op dinsdag 30 januari 2007 @ 13:42:
Trouwens, hoe denken jullie over het toepassen van de moedertaal in de code? Ik zie best wel veel lappen code met Nederlands/Engels gemixt, wat ik persoonlijk best wel ranzig vind Op buitenlandse forums zie ik ook lappen code met termen in het Spaans, Duits en zelfs Chinees

Ik doe het eigenlijk altijd in het engels. Soms dan weet ik even geen zinnige naam aan een variabele te geven en dan heet die tijdelijk 'blaat' oid, maar dat verander ik meestal wel als me een zinnige naam te binnen schiet.

Ik heb een keer gepraat met iemand die bij TI aan het werken was aan assembly-code voor de TI-83+, en die moest een stuk code van een spaans-amerikaans vrouwtje debuggen.

Dat was dus iets als

code:

bla1:
  LD A, B
bla2:
  DJNZ bla1
...
...
...
bla273:
...
...

En vul dan voor bla een of ander vaag non-descriptive spaans woord in.

[Mafkees]

Mastermind schreef op dinsdag 30 januari 2007 @ 12:46:
Ik programmeer op deze manier. Ik mag graag compact programmeren, omdat je dan niet zoveel hoeft te scrollen en een goed overzicht hebt over de code.

Een gedeelte van een programma dat ik heb geschreven, toont bijv. aan hoe handig turnaries zijn:

C#:

string ExternContractnr = factuurEnt.TestCurrentFieldValueForNull(FactuurFieldIndex.ExternContractnr) ? "" : factuurEnt.ExternContractnr.Trim();
while (reportNameExists)
{
      achtervoegselStr = (achtervoegsel++).ToString().PadLeft(2, '0');
      TheNextFileName = ExternContractnr.IndexOfAny(Path.GetInvalidFileNameChars()) > 0 || ExternContractnr == ""
       ? aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses.pdf"
       : aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses " + ExternContractnr + ".pdf";
                
       testFilename1 = Path.Combine(finaldir1, TheNextFileName);
       if (alsoTheEditMap)
        {
             testFilename2 = Path.Combine(finaldir2, TheNextFileName);
             testFilename3 = Path.Combine(finaldir3, TheNextFileName);
        }

         reportNameExists = (File.Exists(testFilename1) ||  ((alsoTheEditMap && File.Exists(testFilename2)) || (alsoTheEditMap && File.Exists(testFilename3))));
}

Deze code vind ik voornamelijk onduidelijk omdat er 0,0 commentaar bij staat. Verder ga ik grotendeels mee met het commentaar dat al eerder geleverd is maar commentaar in code vind ik een vereiste.

Als ik samenwerk aan een project met iemand en de ander schrijft er geen commentaar bij spreek ik iemand er direct op aan. Vaak krijg je dan te horen van dat doe ik later wel... Hoeveel moeite is het om direct commentaar erbij te schrijven, daar heb je zelf alleen maar baat bij. Tenzij je van plan bent om de hele code te herschrijven omdat het een prototype is maar da's vaak niet zo. Mijn mening over commentaar is dan ook: doe het direct, dan staat het er. Het scheelt je een hoop werk achteraf en je kunt het ook niet meer vergeten.

BalusC schreef op dinsdag 30 januari 2007 @ 13:42:
Trouwens, hoe denken jullie over het toepassen van de moedertaal in de code? Ik zie best wel veel lappen code met Nederlands/Engels gemixt, wat ik persoonlijk best wel ranzig vind Op buitenlandse forums zie ik ook lappen code met termen in het Spaans, Duits en zelfs Chinees

Voor mijn werk moet ik het Nederlandse taal helaas wel toepassen in de namen van de klassen, methoden en variabelen. Maar voor eigen projectjes zou ik het 100% in het Engels houden. Niet alleen voor de uniformiteit (de sleutelwoorden en operatoren van de codetaal zijn immers ook in het Engels), maar ook voor een betere (internationale) uitwisselbaarheid

Ik schrijf mijn code altijd in het Engels, het commentaar erbij gaat in het Nederlands. Misschien beetje krom en zou het commentaar ook in het Engels moeten maar goed, projecten zijn tot dusver enkel voor Nederlandse bedrijven gemaakt.

[BalusC]

.oisyn schreef op dinsdag 30 januari 2007 @ 13:44:
[...]

OMG . Ik vind dat er zo onprofessioneel uitzien altijd. Wij werken met amerikanen en australiers, dus een andere taal dan Engels is sowieso al geen optie, maar zelfs zonder die situatie zouden we hier in het Engels programmeren

Dat was de eis van de klant van de huidige projecten (klant is koning enzo ). Maar voor de rest zijn collega's het wel mee eens dat alles in het Engels zou moeten

Mafkees schreef op dinsdag 30 januari 2007 @ 13:53:
Ik schrijf mijn code altijd in het Engels, het commentaar erbij gaat in het Nederlands. Misschien beetje krom en zou het commentaar ook in het Engels moeten maar goed, projecten zijn tot dusver enkel voor Nederlandse bedrijven gemaakt.

Javadoc's zou ik ook gewoon in het Engels doen. De papieren documentatie van de werking van het geheel kan natuurlijk in alle willekeurige talen geschreven worden.

[ Voor 32% gewijzigd door BalusC op 30-01-2007 13:57 ]

[Mafkees]

BalusC schreef op dinsdag 30 januari 2007 @ 13:54:
Javadoc's zou ik ook gewoon in het Engels doen. De papieren documentatie van de werking van het geheel kan natuurlijk in alle willekeurige talen geschreven worden.

Heb je idd wel een punt.. Ik ga binnenkort (as in vanavond/morgen) beginnen met een nieuw project in PHP en gebruik altijd Java-style documentatie. Ook voor PHP zijn er paketten die dan een mooie website met documentatie kunnen genereren, da's in het Engels vaak dus ook beter als dat in het Engels is idd.

Overtuigd

[JKVA]

BalusC schreef op dinsdag 30 januari 2007 @ 13:54:
[...]

Dat was de eis van de klant van de huidige projecten (klant is koning enzo ). Maar voor de rest zijn collega's het wel mee eens dat alles in het Engels zou moeten

[...]
Javadoc's zou ik ook gewoon in het Engels doen. De papieren documentatie van de werking van het geheel kan natuurlijk in alle willekeurige talen geschreven worden.

Het verschil is vooral dat .oisyn games maakt en zelf zijn domein bepaalt. Ik (en ik denk ook jij) werken aan (waarschijnlijk maatwerk) opdrachten voor klanten. En als dat klanten zijn met een Nederlands domein, welke veel Nederlandse termen bevat, die ook als wens/eis opgeven dat het Nederlands moet zijn, is de keuze voor Nederlands snel gemaakt.

JavaDoc zou ik in dezelfde taal doen als de code.

[.oisyn]

JKVA schreef op dinsdag 30 januari 2007 @ 14:12:

Het verschil is vooral dat .oisyn games maakt en zelf zijn domein bepaalt.

Technisch gezien is Crystal Dynamics onze klant en leveren wij net zoveel maatwerk

Ik (en ik denk ook jij) werken aan (waarschijnlijk maatwerk) opdrachten voor klanten. En als dat klanten zijn met een Nederlands domein, welke veel Nederlandse termen bevat, die ook als wens/eis opgeven dat het Nederlands moet zijn, is de keuze voor Nederlands snel gemaakt.

Leveren jullie de code ook aan de klant? Of blijven jullie ter ondersteuning. Want indien dat laatste maakt het natuurlijk ook niet uit - het gaat erom dat het product werkt en in het Nederlands is, ongeacht hoe dat is gemaakt. En wat als jullie bedrijf nou besluit een deel te outsourcen? Ook daar heeft de klant niets mee te maken, edoch zullen die Indiërs weinig van je Nederlands snappen (niet dat het in het Engels zoveel beter gaat, maar dat terzijde )

JavaDoc zou ik in dezelfde taal doen als de code.

Als het uitmaakt dat de code in het Nederlands is, dan lijkt het me helemaal gewenst dat de documentatie dat natuurlijk ook is.

[ Voor 11% gewijzigd door .oisyn op 30-01-2007 14:28 ]

[JKVA]

.oisyn schreef op dinsdag 30 januari 2007 @ 14:26:
Technisch gezien is Crystal Dynamics onze klant en leveren wij net zoveel maatwerk

Maar die bepalen ook wat voor spel het wordt? Of hebben jullie zelf een concept en ontwerp?

Bij een Engelstalige klant is het natuurlijk sowieso geen probleem. Volgens mij is iedereen het hier er wel mee eens dat Engels mooier is.

Leveren jullie de code ook aan de klant? Of blijven jullie ter ondersteuning. Want indien dat laatste maakt het natuurlijk ook niet uit - het gaat erom dat het product werkt en in het Nederlands is, ongeacht hoe dat is gemaakt. En wat als jullie bedrijf nou besluit een deel te outsourcen? Ook daar heeft de klant niets mee te maken, edoch zullen die Indiërs weinig van je Nederlands snappen (niet dat het in het Engels zoveel beter gaat, maar dat terzijde )

Bij mijn huidige project krijgt de klant de source code. Maar het onderhoud wordt wel bij ons gedaan. Bij een speciale app management afdeling.

Outsourcing speelt nog niet, maar komt gegarandeerd nog. We werken nu al samen met Tsjechen en het is een groot Europees bedrijf, dus ik verwacht dat het nog weleens internationaal gaat.

Als het uitmaakt dat de code in het Nederlands is, dan lijkt het me helemaal gewenst dat de documentatie dat natuurlijk ook is.

Eens

[.oisyn]

JKVA schreef op dinsdag 30 januari 2007 @ 14:53:
[...]


Maar die bepalen ook wat voor spel het wordt? Of hebben jullie zelf een concept en ontwerp?

Wij maken de engine en de tools. Dus wij bedenken helemaal niets aan het spel. Vergelijkbaar met wat jij doet dus neem ik aan.

[ Voor 7% gewijzigd door .oisyn op 30-01-2007 15:31 ]

[JKVA]

.oisyn schreef op dinsdag 30 januari 2007 @ 15:31:
[...]

Wij maken de engine en de tools. Dus wij bedenken helemaal niets aan het spel. Vergelijkbaar met wat jij doet dus neem ik aan.

Aha, dan heb je idd wel iets meer restricties. Ik luister gewoon naar wat de grote baas (klant/architect) wil. Als die vinden dat Nederlands slim is, stel ik wel wat kritische vragen, maar als ze overtuigd zijn van hun gelijk vind ik het best. (beetje politiek )

[BalusC]

De klant is hier een grote speler (RDC/RDW), dan moeten wij wel wat flexibeler zijn