Programmeerstandaarden voor of tegen?

[mmniet]

Ik ben een onderzoek aan het doen en ben geinteresseerd in de voors en tegens voor standaarden in het programmeren. Bij standaarden denk ik niet aan soorten programmeertaal, maar meer de manier waarop je de code schrijft. Denk hierbij aan

• TABS
• Voorwaarde constructies die gebruikt worden (alleen CASE of alleen IFTHENELSE of door elkaar)
• Bepaalde statements aan het begin van een regel
• Afkorten of niet
• Variabelen definieren als je ze pas nodig hebt?
• Commentaar aan het begin of overal tussendoor.
• Etc

Nu duidelijk is wat ik met standaarden bedoel, kunnen we overgaan naar de vragen die ik in mijn onderzoek naar voren wil brengen:

1. Als je aan het programmeren bent, is het dan handig om van te voren een aantal standaarden voor jezelf of met je ontwikkelteam te bespreken/vast te leggen? Of beperkt dit je juist als programmeur?
2. Stel dat je graag met standaarden werkt in je programmeren. Hoe ver moet je dan gaan? Keur je een code af als je ergens tegen je eigen keuzes ingaat? bijvoorbeeld: IF THEN ELSE achter elkaar of elk op een aparte regel?
3. Wat zijn de voordelen van standaarden?
4. Wat zijn de nadelen van standaarden?

Probeer verder zo breed mogelijk te gaan binnen het kader standaarden zoals ik die hier gedefinieerd heb. Ik ben zeer benieuwd naar jullie mening in deze, en hopelijk kunnen jullie bijdragen aan mijn onderzoek.

Ik heb dit onderwerp in dit forumdeel geplaatst omdat ik van mening ben dat je van te voren moet bedenken hoe je gaat programmeren, ik zelf ben namelijk een voorstander van standaarden in programmeren, dus ik doe ook mijn standaarden van te voren definieren in ontwikkelteams.

Ik heb gezocht maar kon niets bruikbaars vinden, misschien dat jullie mijn vragen kunnen beantwoorden, dat draagt in ieder geval bij aan mijn onderzoek.

[TERW_DAN]

Ik denk dat het voornamelijk belangrijk is gestructureerd te werk te gaan, dus netjes indenten, tags consequent op dezelfde regel afsluiten (als in, niet de ene tag sluiten op de regel waar je hem ook opent, en de andere er weer onder, dan zie je dingen over het hoofd).

Als je dit soort 'standaarden' al niet afspreekt dan ga je zeker als je met meerdere personen eraan werkt onnoemelijk mee de mist in.
Dus van tevoren gewoon standaarden definieren en het werkt veel vlotter. Code afkeuren als er iets verkeerd staat gaat misschien wat ver, maar als ik dat soort dingen tegenkom dan 'herschrijf' ik het wel zodat het wel klopt, anders wordt het een zooitje.
De voordelen zijn hierdoor:
- sneller werken
- minder fouten
- makkelijker stukken kunnen aanpassen
- minder ergernis
nadelen:
- ze moeten voor iedereen duidelijk zijn.

[Creepy]

Wil je nu dat wij het onderzoek voor je gaan doen of he je zelf nog bepaalde ideeen? Als je nu eerst eens begint met je eigen ideeen te geven over punt 1 tot en met 4 dan kunnen we daar natuurlijk altijd over discussieren, maar 4 vragen dumpen en verwachten dat wij hier het onderzoek voor je gaan doen is natuurlijk niet de bedoeling.

Daarnaast: niks gevonden? Als ik met google zoek op "coding standard" kom ik o.a. de volgende link tegen: http://www.sitepoint.com/article/coding-standards. Daar staat vast wel wat bruikbaars tussen lijkt me.

[Nick_S]

Ook voor versiebeheer is het vaak verstandig om guidelines te hebben. Als elke ontwikkelaar die een bestand aanpast, z'n eigen "standaarden" erover heen gooit, weet je nooit wat er precies aan de code gewijzigd is. Je ziet alleen dat bijna elke regel is aangepast.

[Standeman]

Met ^^
Er zijn twee dingen die je met standaarden wilt bereiken. Dat is uniformiteit en leesbaarheid. Uniformiteit is er om bijv. differences tussen versies er makkelijk uit te filteren. Ook handig is dat indenting altijd hetzelfde gebeurd, aangezien de code er anders best brak uit kan zien op iemand anders z'n machine.

het belangrijkste vind ik nog leesbaarheid. Als ik een method zie (java), wil ik binnen 5 seconden door hebben wat dat ding doet. Wanneer dat niet zo is, is er iets fouts met die method.

Gelukig gebruiken we hier gewoon allemaal dezelfde code templates en formatters (eclipse). Dus dit soort zaken worden redelijk automatisch geregeld.

1. Als je aan het programmeren bent, is het dan handig om van te voren een aantal standaarden voor jezelf of met je ontwikkelteam te bespreken/vast te leggen? Of beperkt dit je juist als programmeur?

Ja het is handig. Ik zie niet op welke manier het je kan beperken.

2. Stel dat je graag met standaarden werkt in je programmeren. Hoe ver moet je dan gaan? Keur je een code af als je ergens tegen je eigen keuzes ingaat? bijvoorbeeld: IF THEN ELSE achter elkaar of elk op een aparte regel?

Hier heb je auto-formatting voor welke in vrijwel elke IDE te vinden is. Voor het inchecken gewoon even forrmatten en je bent klaar.

3. Wat zijn de voordelen van standaarden?

Uniformiteit en leesbaarheid (zoals ik heb geschreven).

4. Wat zijn de nadelen van standaarden?

Geen nadelen. Hoe je wat neerzet beperkt je niet in creativitiet. Mogelijk dat je in het begin moet wennen aan de stijl, maar dat is alles.

[ Voor 42% gewijzigd door Standeman op 14-08-2007 12:01 ]

[whoami]

Verschillende programmeerstijlen; voor- en nadelen

[InputOutput]

Ik werk sinds een jaar aan een vijf jaar oude codebase waar door tientallen programmeurs een meestal vrij korte periode aan gewerkt is. Er is in die jaren nooit een code standaard geweest.

Als je deze codebase ziet, dan wordt de discussie over wel of niet codestandaarden overbodig: wel dus. Bij elk project dat langer duurt dan een paar maanden en waar je met meer dan 1 persoon aan werkt, heb je codestandaarden nodig. Die zijn misschien niet altijd expliciet (een goede programmeur gaat neemt m.i. de formatting van bestaande code waar hij in werkt zoveel mogelijk over) maar er moet wel overeenstemming over zijn.

Het punt is dat bij een groot software project het verschrikkelijk moeilijk is overzicht te houden en als elk deel of elk bestand op een andere manier is formateerd, wordt je helemaal gek. Je gaat bugs missen, je ziet niet precies wat waar gebeurt, etc.

Vaste formatting (en dus codestandaarden) zijn gewoon nodig als je een groter project hebt dat onderhouden moet worden. Anders wordt het hel om aan te werken. Alleen al doordat (wat iemand anders al zei) als je een verandering maakt aan een bestand, en je moet iemands indentatie-spaties omzetten naar tabs of vice-versa of dos lineendings naar unix lineendings en je wil later met een diff kijken wat je tussen twee versie van het bestand hebt aangepast, dan zie je dus helemaal niet meer wat je nou eigenlijk veranderd hebt.

[Comgenie]

Een vaste code standaard is natuurlijk heel erg handig, vooral tabs. Het scheelt echt qua fouten enzo als je alles gewoon net erin zet.

Verder is het (voor mij) zeer handig om zoiezo bovenaan source files in comments te zetten waarvoor die class/script precies dient, wat erin hoort te komen. Zodat je al duidelijke afspraken hebt waar iedereen die mee werkt telkens aan word herinnert. En vooral de bedoeling is daar om niet af van te wijken. Ja, er is vaak een 'simpelle' oplossing voor veel dingen, maar als je goede afspraken hebt, is dat uiteindelijk het beste.

[Floort]

Ik ben een voorstander van programmeerstandaarden.

Ik gebruik veel Python. Python dwingt je voor een deel om je code goedconsistent neer te zetten. Dit kan je een voordeel of een nadeel noemen, maar ik vind het erg overzichtelijk.

Voor talen die iets minder afhankelijk zijn van white-space (c, java, perl...) is het handig om een coding standaard te volgen, zeker als je samenwerkt met andere mensen. Kijk een beetje rond naar grote opensource projecten waarvan jij de code duidelijk vind. Meestal hebben deze projecten wel een document met coding standards. Mijn c code probeer ik zoveel mogelijk volgens de eisen van het OpenBSD project neer te zetten. Af en toe haal ik mijn code ook nog eens door indent om de laatste slordigheidjes eruit te halen.

Maar het belangrijkste is om samen met je mede-ontwikkelaars afspraken te maken die zo min mogelijk mensen vervelend vinden.

[disjfa]

Hoe zou je willen werken zonder programeerstandaarden in een bedrijf met meer dan 1 persoon. (Met een persoon zijn het nog altijd standaarden, maar dan valt het niet op)

Lijkt mij bijna onmogenlijk. Alleen de standaarden verschillen over het algemeen per bedrijf. Maar dat zijn maar kleine verschillen over het algemeen. Maar standaarden bestaan overal.

[Yoozer]

mmniet schreef op maandag 13 augustus 2007 @ 21:52:
Probeer verder zo breed mogelijk te gaan binnen het kader standaarden

Sorry, deze zin klinkt alsof 'ie letterlijk gecopy-paste is uit een huiswerkopdracht .

TABS

Het is heel eenvoudig: dankzij het verschil in bestandsformaten en inlezen (zelfs plaintext is niet plain) gebruik je gewoon spaties en elke fatsoenlijke IDE doet dit goed.

Voorwaarde constructies die gebruikt worden (alleen CASE of alleen IFTHENELSE of door elkaar)

Dit is ook eenvoudig: de code moet leesbaar zijn. Je kiest voor een constructie omdat die het beste past bij een model: is het een splitsing in wegen of moet je de juiste vorm blokje in het juiste gaatje duwen.

Afkorten of niet

Voor code onleesbaar te maken heb je obfuscators. Alleen als je programmeeromgeving je limiteert qua ruimte moet je dit doen. Je schiet er qua leesbaarheid niet altijd iets mee op; behalve voor bijvoorbeeld interface-elementen (btnDoStuff, lblDoStuff). Namen moeten zo min mogelijk onduidelijkheid scheppen en zo logisch mogelijk zijn.

Variabelen definieren als je ze pas nodig hebt?

Bij een taal die het maken van variabelen niet forceert (de oude VB) is dit problematisch; 1 spelfout en je zit met een compleet nieuwe variabele. Als je 'm al gedefinieerd hebt kan je IDE je tenminste helpen.

Commentaar aan het begin of overal tussendoor.

Goede code is leesbaar en begrijpelijk. Het is lastig om een goede balans te vinden tussen te veel en te weinig informatie, en wee de arme ziel die "functie DoStuff doet "stuff" neertikt en dan geen idee meer heeft van het hoe en waarom. Commentaar in de code is geen vervanging voor functionele en technische specificaties.

Als je aan het programmeren bent, is het dan handig om van te voren een aantal standaarden voor jezelf of met je ontwikkelteam te bespreken/vast te leggen? Of beperkt dit je juist als programmeur?

Je ontwikkelteam heeft als het goed is al standaarden; als je ze zelf nog moet introduceren heb je een groter probleem.

Lees dit maar eens: http://www.joelonsoftware.com/articles/Wrong.html

Ik heb dit onderwerp in dit forumdeel geplaatst omdat ik van mening ben dat je van te voren moet bedenken hoe je gaat programmeren, ik zelf ben namelijk een voorstander van standaarden in programmeren, dus ik doe ook mijn standaarden van te voren definieren in ontwikkelteams.

Tegenvragen:

1) waarom doe je onderzoek? Moet je collega's overtuigen? Dan heeft het gepraat over standaarden weinig zin; je kunt dan beter laten zien zoals bovenstaand voorbeeld van veel programmeurs en onleesbare code hoe het fout gaat.

2) waarom hebben je ontwikkelteams jouw standaarden nodig?

[Plekuz]

Moet je standaarden vastleggen? Ja en nee ...

Standaarden zijn belangrijk, maar zorg er wel voor dat je standaarden een zekere mate van flexibiliteit houden. Dus bijvoorbeeld wel standaarden voor naamgeving van variabelen, maar niet zoals de TS opperde een standaard om altijd case i.p.v. if-then-else te gebruiken. Dat is iets wat uiteindelijk alleen maar tegen je gaat werken.

Voor een aantal programmeertalen zijn reeds algemene standaarden terug te vinden over de naamgeving van variabelen en procedures en zijn er globale lijnen hoe een programma opgebouwd dient te worden. Soms kun je zelfs je eigen programmatuur hier geautomatiseerd op laten controleren. Zo is er voor C# een hele beschrijving beschikbaar met richtlijnen en kun je met het programma FxCop (onder andere) controleren in hoeverre je eigen applicatie aan die standaarden voldoet.

Kortom, je hoeft wellicht niet eens de standaarden zelf te verzinnen. En wat betreft het teruglezen van code van collega's. Over het algemeen is die code ook goed terug te lezen als deze zich niet helemaal conform de standaard is. Het blijft immers dezelfde taal waar jij ook mee werkt.

Ik bedoel: jij zou mijn bovenstaande post wellicht anders geformuleerd hebben om te voldoen aan jouw standaarden van zinsopbouw en dergelijke, maar het blijft nederlands en je snapt prima wat er geschreven is. Dus gebruik standaarden, maar overdrijf niet en ga er niet te rigide mee om.

[djluc]

De vraag is niet of je met standaarden moet werken, dat is geen discussiepunt. Je moet kijken hoe streng je bent en daar onderzoek naar doen. Standaarden zijn er altijd als je aan het programmeren bent, als is het alleen maar dat je if voor else zet bij wijze van spreken.

[JKVA]

In Java heb je de tool checkstyle. Het gebruik van die tool ben ik wel voor, maar volgens mij heeft een concullega op mijn huidige klus de term "CheckStyle Driven Development" bedacht.

Ik kwam het volgende tegen: (voorbeeld ter plekke bedacht, heb de code niet bij de hand, het idee blijft hetzelfde)

Java:

interface NumericConstantsOfzo {
    public static final int L1 = 1;
    public static final int L2 = 2;
    public static final int L3 = 3;
    public static final int L4 = 4;
    public static final int L5 = 5;
    public static final int L6 = 6;
    public static final int L7 = 7;
    public static final int L8 = 8;
    public static final int L9 = 9;
    public static final int L10 = 10;
    ...
    public static final int L34 = 34;
    public static final int L100 = 100;
    public static final int L125 = 125;
    public static final int L1050 = 1050;
}

Java:

@Entity
public class Klant {

    private String naam;

    public void setNaam(String naam) {
        this.naam = naam;
    }

    @Column(name="SCHEMA.NAAM", type="VARCHAR", length=L100)
    public String getNaam() {
        return this.naam;
    }

}

Letterlijk op elke plek waar ook maar een nummer gebruikt werdt, tot aan de annotaties met de veldlengtes werden constanten gebruikt. Begrijp me niet verkeerd, ik vind het goed dat CheckStyle commentaar geeft als je 'magic numbers' gebruikt, maar om voor elk mogelijke getal een constante te maken, puur en alleen omdat CheckStyle klaagt, vind ik nogal dom.

Los van het feit dat het een onzinwerk is om voor elk getal een constante te gaan programmeren die er in je code exact hetzelfde uitziet als het getal, behalve dat er een 'L' voor staat, introduceer je op deze manier gemakkelijk fouten. Ik zie het al voor me. Dit is precies een klasse die je met copy-paste programmeert en stel je de volgende regels eens voor...

Java:

public static final int L21 = 21;
public static final int L22 = 21;

Dan sta je toch raar te kijken als je die constante gebruikt.

Wat wil ik nou zeggen met dit hele betoog? (dat vraag ik mezelf ook af ) Dat coding guidelines en tools die je code controleren heel erg handig zijn, maar je moet niet overdrijven en gezond verstand voorrang geven. Ik ga ervanuit dat de meeste ontwikkelaars gezond verstand hebben. En anders heeft je lead developer dat wel. Die moet dan maar de verantwoordelijkheid nemen om je op je flikker te geven (en uit te leggen waarom jouw manier van coding niet deugt).

[Alain]

Ik ben zelf PLC programmeur en daarnaast programmeer ik een aantal applicatie's om een interface te maken tussen de PLC applicatie's die ik schrijf en de engineer die het moet configureren. Ik was tot voor kort de enige programmeur, maar omdat dat niet werkt (als ik in het buitenland zit is er niet genoeg kennis op gebied van automatisering) moet de kennis op dit gebied breder zijn. Hierdoor moet ik mensen met een elektrotechische achtergrond (heb ik ook) opleiden tot programmeur.

Omdat ik eerder altijd alles zelf deed was het opstellen van een standaard niet aan de orde. Nu ben ik aan het denken om een document op te stellen met regels die gelden voor het schrijven van software binnen ons bedrijf. Hierbij wil ik de fantasie van een nieuwe programmeur niet belemmeren.

Ik bekijk een applicatie van een ander dan ook zoals ik elektrische tekeningen bekijk. Het moet duidelijk leesbaar en logisch zijn, daarbij moet het binnen vooraf gemaakte afspraken vallen. Deze afspraken hebben enkel betrekking op de structuur en niet op de implementatie.

Als we met een club van 10 programmeurs hadden gezeten, zou ik harde regels stellen om de club op 1 lijn te houden. Nu krijg ik elke applicatie van een ander inclusief uitleg en kan ik tijdig bijsturen.

Om een antwoord te geven op je vragen:

mmniet schreef op maandag 13 augustus 2007 @ 21:52:
Als je aan het programmeren bent, is het dan handig om van te voren een aantal standaarden voor jezelf of met je ontwikkelteam te bespreken/vast te leggen? Of beperkt dit je juist als programmeur?

Ik denk dat het belangrijk is om structuur in het werk te brengen. Niet op if, then, else niveau, maar op algemeen denk niveau. Om een voorbeeld te geven: In een simpele applicatie zal ik een goto niet goedkeuren, maar als de programmeur ermee bereikt dat zijn programma beter leesbaar is of beter werkt ga ik ermee akkoord.

Stel dat je graag met standaarden werkt in je programmeren. Hoe ver moet je dan gaan? Keur je een code af als je ergens tegen je eigen keuzes ingaat? bijvoorbeeld: IF THEN ELSE achter elkaar of elk op een aparte regel?

Zoals gezegd lijkt me dit afhankelijk van het aantal programmeurs. Ik krijg elke applicatie regelmatig te zien en kan bijsturen, maar met een groep programmeurs gaat dat niet lukken en moet je eisen stellen. Structureel een aantal regels, maar qua implementatie is iedereen vrij.

Wat zijn de voordelen van standaarden?
Wat zijn de nadelen van standaarden?

Ik denk dat je dit zelf wel kan bedenken of uitzoeken.

[oeLangOetan]

Als je op zoek bent naar goede stijlgidsen:
http://software.gsfc.nasa.gov/ISDpaAll.cfm

[Refro]

Je zou ook hier kunnen beginnen. Wij werken in ieder geval met een eigen standaard en de voordelen zijn veel groter als de nadelen. Alleen voelen sommige mensen zich in hun "vrijheid" beperkt. Ook in combinatie met version control werkt het erg goed omdat je de verschillen in versies beter kan zien. Wij zijn laatst ook naar een andere editor overgestapt en een aantal zaken indentation, polish notation, spatiering, plaatsing accolades etc wordt nu automatisch door de ide geregeld is weer wat minder zorg voor ons.

Nu alleen die ene collega nog afleren functies binnen een file te verplaatsen omdat ie de volgorde dan logischer vindt.