programmeerstijl tips?

[John Sickbock]

Hoi mede-programmeurs

Weet je toevallig ergens een lijstje 'de beste 100 programmeerstijltips' ofzo? Niet dat ik dat nou zo heel slecht doe (geloof ik), maar je weet nooit wat anderen hebben verzonnen dat ik nog niet heb verzonnen.

Ben benieuwd en alvast bedankt!

Tijmen

[CryptapiX]

ik snap niet helemaal wat je bedoeld?

[deathz0rz]

1. Gebruik indent

[Dr HenDre]

gebruik een fatsoenlijke editor(met syntax highlighting en met automatisch inspringen) . Ik weet niet of je dat bedoelt, maar een tip van mijn kant

[JJzD]

spreek met jezelf een manier van afsluiten af
als je het bijvoorbeeld over php hebt, kan je de } onderaan zetten of achteraan en ook weer verschillend inspringen.
Houd je includes zoveel mogelijk bij elkaar als je variabelen laadt.
Gebruik commentaar veelvuldig.
makkelijk in je opzet en weet je wat je aan het doen bent en als je het over een jaar teruglees5t weet je sneller wat er ook alweer gebeurd
vooral het commentarieren van de end haken is erg makkelijk, voor al als je (zoals ik) slordig script en snel zulke dingen vergeet en je 300 regels door moet om } terug te zettten
Controleer of het werkt zo vaak mogelijk.

tot zover mijn ervaringen

[Chimera]

JJzD schreef op 02-08-2003 @ 15:37:

Gebruik commentaar veelvuldig.

Nee, je code moet zonder commentaar leesbaar zijn. Als je code zonder commentaar niet goed te volgen is, is het slechte code.

[JJzD]

Chimera schreef op 02-08-2003 @ 15:48:
Nee, je code moet zonder commentaar leesbaar zijn. Als je code zonder commentaar niet goed te volgen is, is het slechte code.

als je hem 5x indent ben ik wel even de structuur kwijt van dat ding

of wat een pregreplace nou eigenlijk doet is sneller te lezen in een commentaar dan het uit te gaan zoeken

natuurlijk moet het ook te doen zijn zonder, maar het gaat hier om goed, beter best

[deathz0rz]

JJzD schreef op 02-08-2003 @ 15:50:
of wat een pregreplace nou eigenlijk doet is sneller te lezen in een commentaar dan het uit te gaan zoeken

mee eens

[Chimera]

JJzD schreef op 02-08-2003 @ 15:50:
als je hem 5x indent ben ik wel even de structuur kwijt van dat ding

of wat een pregreplace nou eigenlijk doet is sneller te lezen in een commentaar dan het uit te gaan zoeken

natuurlijk moet het ook te doen zijn zonder, maar het gaat hier om goed, beter best

Daarom zeg ik ook dat _code_ per definitie duidelijk genoeg moet zijn, een functie mag in princiepe niet veel langer zijn dan een pagina (uitzonderingen daargelaten), en een regexp is geen code.

Wat je dus ziet bij mensen is dit:

int i;                                    //Integer definieren.
for(i = 0;i < collection.size();i++)         //For loop
{      
     Object o = collection.get(i);            //Object ophalen
}

M.a.w, praktisch elke regel code is gedocumenteerd terwijl de code zelf precies zegt wat 'ie doet. In sommige gevallen is extra uitleg handig, maar in princiepe MOET code zelf zo leesbaar zijn dat documentatie niet nodig is. Het is ook nog eens minder werk, bovendien hoef je niet je documentatie te onderhouden, wat voor extra problemen kan zorgen.

[Chimera]

deathz0rz schreef op 02-08-2003 @ 15:51:
mee eens

Best, maar een regexp is een regexp, geen C/Java/Whatever code, en daar hebben we het hier over.

[deathz0rz]

Chimera schreef op 02-08-2003 @ 15:56:
Best, maar een regexp is een regexp, geen C/Java/Whatever code, en daar hebben we het hier over.

dit is geen code?

$patt="!(<\\?php.+\\?>)!ismU";
$result=preg_replace($patt,'',$r);
$patt="!(<.+>)!ismU";
$result=preg_replace($patt,'',$result);
$patt="!\s+!ism";
$result=preg_replace($patt,' ',$result);

$key='en';
$offset=70;
$patt="!.{0,".$offset."}\s".$key."\s.{0,".$offset."}!ism";

foreach ($result as $name => $page) {
preg_match_all($patt,$page,$x);
print_r($x);
$r[$name]=$x;
}

[dafelix]

*zucht* over bovenstaande berichen


anywayz, volgens mij is een goede tip voor programmeren, dat je programma snel moet zijn

Als je met VB (of QBasic van mijn part) heb je daar weinig last van, omdat je code nog een keer word omgezet naar een progje

programmeer je echter in "echte-programeertaal" (is geloof ik een naam voor) zoals Assembly maakt het enorm veel uit

Iedereen programmeerd anders, iedereen schrijft anders, de een vind het een beter, de ander juist niet. Het is nogal persoonsgebonden.

(Oh PS: over die comment, ik vind dat je zoveel comment mag plaatsen als je zelf wilt, omdat dat voor de een makkelijk is)

[Chimera]

deathz0rz schreef op 02-08-2003 @ 16:01:
dit is geen code?

Ja, maar dat was het aanroepen van regexp functies, een regexp zelf is gewoon een string, en die dient wel gedocumenteerd te worden snap je?

[Chimera]

dafelix schreef op 02-08-2003 @ 16:17:

programmeer je echter in "echte-programeertaal" (is geloof ik een naam voor) zoals Assembly maakt het enorm veel uit

Nee hoor, het verschil tussen assembly en C is heel klein, de meeste compilers zijn slimmer dan mensen, en C coden en de compiler laten optimisen is zowel makkelijker als beter. Vooral grote programma's zijn gewoon niet in assembly te schrijven.

[deathz0rz]

Chimera schreef op 02-08-2003 @ 16:21:
Ja, maar dat was het aanroepen van regexp functies, een regexp zelf is gewoon een string, en die dient wel gedocumenteerd te worden snap je?

*zucht*

[Chimera]

deathz0rz schreef op 02-08-2003 @ 16:23:
*zucht*

Wat nou *zucht* snotaap? Wil jij beweren dat een regexp geen 'onleesbare' string is?

[M@rco]

Chimera schreef op 02-08-2003 @ 16:24:
Wat nou *zucht* snotaap? Wil jij beweren dat een regexp geen 'onleesbare' string is?

Ghehe... idd

't Is nogal ontmoedigend voor mensen die net met een programmeertaal beginnen als ze gelijk iets als dit zien staan:

$filename =~ s~\A([\+\<\>]{0,3})[\+\<\>]*~~;

[Chimera]

M@rco schreef op 02-08-2003 @ 16:28:
Ghehe... idd

't Is nogal ontmoedigend voor mensen die net met een programmeertaal beginnen als ze gelijk iets als dit zien staan:

$filename =~ s~\A([\+\<\>]{0,3})[\+\<\>]*~~;

Nou, dat is al redelijk duidelijk, een filename check, maar dit soort harde strings zijn dus net voorbeelden van dingen die wel gedocumenteerd moeten worden. Net zoals magic numbers.

[John Sickbock]

hot topic

Mijn vraag was dus eigenlijk of iemand een site ofzo weet waar een grotere lijst met tips staat. Weet iemand zoiets?

Verder: mooie discussie En Chimera: mooie sig

[IceManX]

Chimera schreef op 02-08-2003 @ 15:55:
Daarom zeg ik ook dat _code_ per definitie duidelijk genoeg moet zijn, een functie mag in princiepe niet veel langer zijn dan een pagina (uitzonderingen daargelaten), en een regexp is geen code.

Wat je dus ziet bij mensen is dit:

int i;                                    //Integer definieren.
for(i = 0;i < collection.size();i++)         //For loop
{      
     Object o = collection.get(i);            //Object ophalen
}

M.a.w, praktisch elke regel code is gedocumenteerd terwijl de code zelf precies zegt wat 'ie doet. In sommige gevallen is extra uitleg handig, maar in princiepe MOET code zelf zo leesbaar zijn dat documentatie niet nodig is. Het is ook nog eens minder werk, bovendien hoef je niet je documentatie te onderhouden, wat voor extra problemen kan zorgen.

Dit is idd zwaar overdreven, maar soms is het in code wel nodig. Zo moest ik in Java een byte array naar longs converteren. Aangezien die bytes om een of andere reden soms negatief waren moest ik er soms 256 bij optellen. Zonder commentaar is dat niet even duidelijk voor iemand.

Ik heb net even wat van mijn oude code door zitten kijken, en ik gebruik daar vooral commentaar om te vertellen WAAROM ik iets doe (of niet doe), of bepaalde condities even neerzetten om duidelijk te maken dat checks niet nodig zijn oid (bv: x > 0, dan hoef je niet te checken op <= 0).

Commentaar over WAT je doet is vrijwel alleen maar nodig bij obscure code (en die moet je imho toch wel zoveel mogelijk vermijden).

[IceManX]

John Sickbock schreef op 02-08-2003 @ 17:06:
hot topic

Mijn vraag was dus eigenlijk of iemand een site ofzo weet waar een grotere lijst met tips staat. Weet iemand zoiets?

Verder: mooie discussie En Chimera: mooie sig

Zoek op google naar de Java coding standard.
Deze twee had ik zo gevonden:
Java Coding Standard
Code Conventions for the Java Programming Language

Hoewel ze coding standard en coding conventions zeggen, zijn het niet meer dan tips. Je hoeft je er ook niet aan te houden, je kunt adh hiervan je eigen standaard maken.

[Chimera]

IceManX schreef op 02-08-2003 @ 17:15:
Hoewel ze coding standard en coding conventions zeggen, zijn het niet meer dan tips. Je hoeft je er ook niet aan te houden, je kunt adh hiervan je eigen standaard maken.

Als je alleen voor jezelf programmeert niet, maar als je in een bedrijf werkt zijn dat gewoon regels.

[Chimera]

IceManX schreef op 02-08-2003 @ 17:12:
Commentaar over WAT je doet is vrijwel alleen maar nodig bij obscure code (en die moet je imho toch wel zoveel mogelijk vermijden).

Klopt, maar nogmaals, documentatie alleen als het nodig is, niet omdat je moet documenteren. Code moet op zichzelf netjes genoeg zijn.

[Orion]

How To Write Unmaintainable Code


Misschien heb je hier wat aan

[Manuzhai]

De desbetreffende FAQ op GoT.

Overigens ben ik het met Chimera eens dat je niet elke overduidelijke regel hoeft te documenteren en dat je code vanzelf leesbaar moet zijn (dat wil zeggen, gebruik duidelijke namen voor variabelen e.d.), maar ik denk dat het belangrijk is om de grote lijn van wat je aan het doen bent wel duidelijk te documenteren.

[-niels-]

Chimera schreef op 02-08-2003 @ 15:55:
Daarom zeg ik ook dat _code_ per definitie duidelijk genoeg moet zijn, een functie mag in princiepe niet veel langer zijn dan een pagina (uitzonderingen daargelaten), en een regexp is geen code.

en wat is een 'pagina' ???

verder geef ik je groot gelijk, elke regel vind ik ook overdreven... maar ik vind het bijv. heel handig als bij de start van elke functie of niet meteen duidelijk onderdeel even staat wat het is en kort wat het doet... maar goed, das persoonlijk...

[Screaming Slave]

een a4 vel met de code in courier 10 punts neem ik aan dat ie bedoelt

[niemand]

Crystal Method schreef op 03-08-2003 @ 17:04:
een a4 vel met de code in courier 10 punts neem ik aan dat ie bedoelt

Ik vind dat best kunnen.
Het hangt maar van je functie af.

[IceManX]

nog even een tip: beperk zoveel mogelijk het aantal karakters per regel. Laat dit bij voorkeur niet boven de 80 karakters (nee geen typo, eerder een thinko ) uitkomen (ivm het goed kunnen afbeelden op vrijwel elk scherm), als het kan niet boven de 70 (ivm printers).

Verder ben ik het er mee eens dat een functie over het algemeen niet boven de 100 regels uit moet komen (uitzonderingen daargelaten). Mocht je functie langer worden, dan kun je vrijwel altijd van delen van die functie subfuncties maken.

[deathz0rz]

IceManX schreef op 03-08-2003 @ 17:37:
nog even een tip: beperk zoveel mogelijk het aantal karakters per regel. Laat dit bij voorkeur niet boven de 80 regels uitkomen (ivm het goed kunnen afbeelden op vrijwel elk scherm), als het kan niet boven de 70 (ivm printers).

typo?

[IceManX]

deathz0rz schreef op 03-08-2003 @ 17:48:
typo?

gefixed

[Gimme more beer]

Heb laatst met iemand gesproken die een zware online applicatie in PHP had geschreven en eigenlijk 1 grote file had waarin al z'n functies zaten etc.

Dat was meteen de enige file die je had en die zette je in de root van die applicatie. Alleen wat temp files en mysql vielen buiten deze file, maar alle instellingen en data die je gewoonlijk in een file stopt zaten er ook gewoon in.

Opzich wel leuk, geen probleem natuurlijk, maar deze file was zo'n 1400 KB groot en bij het veranderen zeer onoverzichtelijk.

Hoewel het misschien moeilijker mag lijken, raad ik daarom altijd aan om functies altijd in te delen in functiegroepen en deze in aparte files te stoppen en die dan weer in bepaalde mappen te stoppen. Zo moet je misschien af en toe wat meer typen, maar het risico dat je de verkeerde dingen (die misschien op de goede lijken) gaat editen wordt kleiner en voor iemand die er eens een keer naar wil kijken wordt het ook een stuk overzichtelijker...

Een file van 1400 KB (zo'n 1.400.000 tekens) is gewoon echt niet makkelijk te overzien. Qua snelheid maakt het opzich ook niet uit.
Roep ook je functies vanuit aparte files aan, want het is onzin om al je functie files te moeten includen vanuit je index. Kortom, werk ook met page includes.

[niemand]

Gimme more beer schreef op 06-08-2003 @ 13:48:
Hoewel het misschien moeilijker mag lijken, raad ik daarom altijd aan om functies altijd in te delen in functiegroepen en deze in aparte files te stoppen en die dan weer in bepaalde mappen te stoppen.

Ik zou aanraden om ze dan gelijk netjes in classes te gooien.

[Manuzhai]

niemand schreef op 06-08-2003 @ 14:25:
Ik zou aanraden om ze dan gelijk netjes in classes te gooien.

Dat hangt er maar net van af of je dat paradigma gebruikt. Beetje nutteloos om zomaar alles in classes te gooien, als je OO wilt programmeren, moet je het goed doen.

[Gimme more beer]

niemand schreef op 06-08-2003 @ 14:25:
Ik zou aanraden om ze dan gelijk netjes in classes te gooien.

Dat kun je doen, dat is je eigen stijl. Ik gebruik ze bij de ene website weer wel en bij de andere weer niet.