Waarom ben je een slechte programmeur

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • We hebben allemaal onze slechte gewoontes. In dit artikel gaan we een lijst af met slechte gewoontes van programmeurs die wij vervolgens bestuderen, evalueren en corrigeren.

    Wie denk je dat je bent?

    Elke keer als ik een project open dat niet van mij is blijf ik me afvragen in wat voor "Temple of Doom" ik nou weer terecht kom. Code vol valkuilen, geheime namen en wanneer ik 1 regel code aanpas verandert dit de hele applicatie.


    Wanneer dit niet het geval is alles prima. Er zullen slechts enkele verschillen zijn in de denkwijze van elk individue een gevalletje "Hoe ik het gedaan zou hebben...". Een hele opluchting en je komt makkelijk een project door.

    Wanneer je wel een "Temple of Doom" hebt gecreëerd zal je al snel de reactie krijgen "Wie is deze gozer?". Terecht, want welke programmeur zou gebruik willen maken van jouw code als het een grote puinhoop is...

    Je eerste instinct bij dit probleem is de veronderstelling dat het project gemaakt is door een beginnende programmeur of dat deze persoon gewoon idioot is, maar dit is niet altijd het geval.

    Mijn in theorie is slechte code een opeenhoping is van meerder shortcuts en concessies (afgekorte variabelen, geen commentaar etc.). Dit maakt de "Temple of Doom" alleen maar erger, omdat het misschien slim en snel lijkt, uiteindelijk ben je gewoon lui en raffel je een applicatie alleen maar af. De eerstvolgende persoon die jouw code opent zal in tranen uitbarsten omdat hij geen idee heeft wat er staat.

    Dit kun je verbeteren
    Het kan nooit kwaad om je huidige gedrag opnieuw te onderzoeken en ervoor te zorgen dat je code leesbaar blijft voor andere gebruikers. In een paar minuten tijd en een aantal tips kan je al snel je code beter indelen en een groot deel van deze slechte gewoontes wegnemen:
    1. Voordat je slechts een regel code schrijft moet je een plan van aanpak hebben. Op deze manier voorkom je dat code gaat verwarren en krijg je goed inzicht hoe de structuur van jouw applicatie eruit gaat zien. Schrijf daarom eerst eens je document vol met commentaar, dit heeft dezelfde werking als een boodschappenlijstje: je blijft er mee op de goede weg wanneer je een klus wilt afmaken.
    2. Vermijd geen commentaar. Een van de grootste problemen die ik tegenkom is dat het commentaar slecht is of zelfs ontbreekt. Dit kost misschien 1 minuut extra tijd, maar na 2 maanden niet gewerkt te hebben aan een project kost dit weinig hersencapaciteit om dit later weer op te pakken.
    Kortom geen excuses meer, schrijf ALTIJD commentaar.

    Je offert duidelijkheid op voor beknoptheid

    Het is een verleiding om iets te doen met zo weinig mogelijk letters. Goede voorbeelden van het opofferen van duidelijkheid is het kiezen van onduidelijke variabelen (zoals $a - alleen wat doet $a?) en het schrappen van accolades.

    Het weglaten van accolades is naar mijn mening altijd onverantwoord, het is gewoon te makkelijk om de acties te verliezen zonder deze twee handige symbolen. Natuurlijk is dit niet in elke taal mogelijk (Python bijvoorbeeld), maar het toevoegen van accolades verduidelijkt een actie enorm, wanneer je code laat inspringen.

    U houdt zich niet aan een Coding Standard

    Kies een standaard en hou je eraan


    Uw opmaak kan voldoen aan uw artistieke drang, maar het is niet goed voor iedereen. Kies een standaard (ik adviseer de PSR-4 coding standard) en hou je daaraan. Iedereen zal u dankbaar zijn (inclusief uzelf, op een dag).

    Als je gaat programmeren moet je denken dat het een gesproken taal is. Grammatica en interpunctie bestaan er om een reden: zo kunnen we duidelijk elkaar begrijpen als we dingen opschrijven. Denk niet dat je hierdoor een saai persoon bent.

    U dupliceert code

    Probeer te kijken naar elk stuk van uw applicatie als iets dat zal moeten veranderen op één punt. Als het zo is dat u meer dan één bestand moet bijwerken, dan is het tijd om uw code te evalueren. Wanneer je vervolgens code hebt die hetzelfde doet op meerdere plekken in uw applicatie, dan doe je toch echt iets verkeerd.

    U maakt geen gebruik van design patterns

    Je moet altijd een structuur hebben wanneer je programmeert. Hierbij bedoel ik niet dat je jezelf vast moet klemmen aan het MVC pattern, maar ik denk dat je moet weten hoe je componenten moet classificeren en moet weten waar ze heen gaan.

    Door het volgen van design patterns, worden veel beslissingen automatisch geregeld, en iemand die je code leest of niet veel te denken bij het zoeken naar bepaalde functionaliteiten.

    Het duurt niet lang, en het zal echt je applicaties verduidelijken.

    We zijn allemaal schuldig

    Zelfs wanneer we het goed doen moeten we altijd verbeteren. Ik weet dat wanneer ik terug kijk op code die ik schreef in het verleden dat ik ook geschokeerd raak.

    We zullen nooit perfect zijn, maar we kunnen alles er aan doen om er voor te zorgen dat we het zo makkelijk mogelijk maken voor onze mede programmeurs.

    Wat zijn uw ergenissen bij het omgaan met andere ontwikkelaars? Laat het weten in de comments!
    Dit was mijn spreekbeurt, zijn er nog vragen?

    1,691 times read

Comments 5

  • Stefan.J -

    @stijnhau: Inderdaad! Het probleem van documentatie en code, is dat het met elkaar moet kloppen. Ik ben dan ook helemaal geen voorstander van commentaar in code. Zodra je ziet dat je (inline) commentaar moet gaan schrijven, is je code gewoon niet beschrijvend genoeg. Dus: schrijf geen commentaar, maar maak je code leesbaar met duidelijke variabele namen, methode namen en niet te grote methoden.

  • victor -

    @M.Martens Zeker niet ouderwets hoor. Het is erg handig om een overzicht te hebben van bijvoorbeeld je mappenstructuur, verschillende functies en databases. Hier is ook een hoop software voor. ;)

  • stijnhau -

    Imand die geen acolades gebruikt mogen ze van mij echt tegen de muur zetten. Commentaar maak ik me zelf ook vaak schuldig aan(Probeer er wel op te letten) en $arr = array is denk ik mijn meest gebruikte variabele. Meestal komt dat omdat ik iets probeer dan iiets anders en dan geen documentatie meer doe. Hte alstigste zelf viond ik als je documentatie doet en dan de code en dan je code iets moet aanpassen zodat die documentatie er wel is maar nioet 100% klopt met de code da is aps storend.

  • M.Martens -

    Erg duidelijk! Mensen zullen mij wel ouderwets vinden denk ik maar ik schrijf nog mijn projecten uit in een A4 schrift. (Zo verleer ik het schrijven niet). Dit voor het gemak maar ook mocht ik iets vergeten zijn op te slaan heb ik het meestal weer snel gemaakt met mijn aantekeningen in het schrift.

  • L.Groot -

    Erg duidelijk artikel en 100% gelijk! De ergste code die ik ooit gezien heb was een code zonder inspringen, accolades, duidelijke variabelnamen en commentaar. Om zelfmoord te vermijden heb ik het project zelf maar vanaf 0 opnieuw geschreven. Zelf spring ik altijd in, maak ik altijd gebruik van accolades. Daarbij gebruik ik op veel kritieke punten commentaar (al kan ik dit nog wel verbeteren en vaker doen) en gebruik ik meestal duidelijke variabelnamen, of anders leg ik uit wat ze betekenen in commentaar of in een handleiding. Desalniettemin een duidelijk artikel en zeker voor iedereen (ook ervaren programmeurs) het lezen waard!