Schone code: hoe ik kwaliteit probeer te leveren

Recentelijke vroeg oud-stagiair bij Tam Tam Jeff Simons of ik wat quick wins voor hem had voor het schrijven van ‘schone code’(*). Nu gruwel ik van de talloze top 10′s en nu-echt-definitieve-en-complete bijbels op internet, omdat er heus geen universele manier van werken is die voor iedereen het gewenste effect heeft, en ik heb zeker niet de illusie dat mijn manier van werken dat wel is. Wat ik wel kan doen is een aantal methodieken delen waarmee ík mijn werk doe, en wie weet is dit voor jou – de aandachtige lezer – relevant.

Contentbeheerders zijn ook maar gewoon mensen

Contentbeheerders zijn doorgaans de meest onderschatte doelgroep van front-end developers. De mensen achter de schermen, die dag in, dag uit bezig zijn met het aanvullen, verdiepen en optimaliseren van jouw telg maken of kraken het succes ervan. Als deze mensen niet goed worden gefaciliteerd, en als hun acties niet netjes worden opgevangen middels een solide front-end, kunnen al je andere doelgroepen wel fluiten naar de informatie die ze zoeken.

Als front-end developer kan ik tevens bevestigen dat contentbeheerders op wonderlijke wijze vaak precies dátgene proberen te doen waar je het allemaal niet voor hebt gemaakt. Noem het een collectieve gave. Dat betekent echter wel dat je als front-end developer een waterdichte manier van werken moet hebben, en dat is zo ongeveer de enige echte complexiteit in ons vak. Gratis tip: Praat met ze. Het zijn doorgaans hele normale mensen. Spendeer een uur of 2 aan hun bureau en kijk ze op de vingers. Ervaar hun werk, zie wat ze doen en wat er gebeurt als zij content kloppen. Het zal je verbazen hoeveel profijt je hebt van zo’n, tsja…noem het een gebruikerstest. Zo ontdekte ik dat bij de Kamer van Koophandel regelmatig de behoefte bestond om een <ul> te laten volgen op een inleidende <p>. Als je echter alle <p>’s een standaard marge van 20px aan de onderzijde hebt gegeven, dan lijkt de <ul> niet langer bij de <p> te horen. Dat zijn dus visuele fouten waar zelden op wordt geanticipeerd in een ontwerp, en met al te generieke code niet kunnen worden opgevangen. In dit soort gevallen kun je de editor aan de serverkant voorzien van een aantal regular expressions waarmee je deze situaties kunt afvangen.

Ontwerpers houden van unicorns

Dat een artikel in het ontwerp exact even hoog is als het blokje ernaast is hartstikke leuk, maar zo’n ontwerper kun je het beste middels een fikse oplawaai op het achterhoofd uit zijn of haar droom helpen. In de praktijk is dat namelijk een unicum, en ook al spreek je met de klant nog zo goed af dat het echt maar 5 items van maximaal 30 karakters mogen zijn; er komt een dag dat het misgaat. Jouw verantwoordelijkheid, jouw schuld. Scenario 1: In de psd vind je 3 mooi vormgegeven lijstjes op de homepage. Ieder lijstje heeft 5 items, en ieder item is slechts een paar woorden. Lijntje aan de onderkant, icoontje aan de linkerzijde, lekkere witruimte met een line-height van 22 pixels. Alsof het er voor gemaakt is! Vervolgens vult een contentbeheerder de boel in naar behoren, maar wacht; er is een extra item dat iets langer is dan wat we hebben afgesproken. Resultaat:

Ergo, vang dit soort zaken af. Het is bedroevend hoe vaak je dit kunt tegenkomen in sites die al maandenlang live staan. Het is een kleine moeite voor de ontwikkelaar, lijkt me. Regels zijn er om te overtreden; zo ook de afspraken die een beheerder maakt met jou over jouw bloed, zweet en tranen. Het is een kleine moeite om lijsten, koptitels en links klaar te maken voor content welke over twee regels zal lopen, of langer is dan afgesproken.

Denk na over verschillende resoluties en touch

Probeer bij het schrijven van je stylesheet na te denken over het type gebruik dat je kunt verwachten. Praat met je interactie-ontwerper over de te verwachten gebruikersscenario’s. Als de verwachting is dat gebruikers veelal de site zullen benaderen via mobiele telefoons is het goed om hier in je interactie rekening mee te houden. Toevallig kwam ik dit voorbeeld enkele weken geleden helaas tegen in het werk van een collega: absoluut een gemiste kans.

Op zich is er doorgaans weinig mis met het bovenste, rode linkje. Gebruikers bewegen met de cursor naar het element, en zodra het pijltje verandert in een handje wordt er geklikt. Bij het gebruik van een touch-apparaat is dergelijke feedback echter niet aan de orde, en is de verwachting bovendien dat het gehele blauwe vlak klikbaar is, omdat je vinger nu eenmaal hoe dan ook te groot is om louter tekst te raken. Het is een kleine moeite om je code direct uit te breiden met het gewenste display: block; en op die manier altijd je links het maximale formaat te geven zoals in de groene link in het voorbeeld.

Wat betreft de verschillende resoluties: webheld Luke Wroblewski stelt dat het goed is om een website te beredeneren alsof je het voor een mobiele telefoon ontwikkelt. Hier geeft hiervoor een aantal redenen:

• Het dwingt je de site te beperken tot de informatie die er echt toe doet, of in ieder geval vanuit dat perspectief de site op te bouwen.
• Mobiel heeft de toekomst; groeit veel sneller dan het gebruik van PC’s ooit heeft gedaan, dus je kunt er maar beter klaar voor zijn.
• Laadtijden doen er opeens weer toe. Misschien toch aan de sprites of slimmer omgaan met je save for web-gedrag?

Ik test al mijn sites door op mijn iPad en een smartphone. Niet omdat ze specifiek voor deze platformen zijn ontwikkelt, maar omdat het een goede controle is voor de kwaliteit van wat ik oplever.

Meestvoorkomende open deur: het scheiden van content van opmaak en gedrag.

Rustig, rustig, ik weet ook heus wel dat ruim 99% Javascript gewoon heeft aanstaan. Je hoeft zo’n variant ook niet apart te ontwerpen, maar door het wel te berederen dwing je jezelf om goed na te denken over de gelaagdheid van je product, en voorkom je dat de klant van jouw klant een vreemde kennismaking heeft met het product en je klant omzet misloopt door jouw laksheid.

Maar eigenlijk is dat allemaal bijzaak ten opzichte van de essentie; zorg dat alle informatie altijd voor iedereen vindbaar is en je wint automatisch terrein op zaken als toegankelijkheid, vindbaarheid en onderhoudbaarheid van je code. Dát vormt de kwaliteit van wat je oplevert, en dát maakt het verschil tussen ‘veel geld’ en ‘duur’

* Tijdens mijn studie betichtte mijn twee goede vrienden, optimalisatie-guru Roel van der Ven en datavisualisatie-orakel Jasper Schelling mij van code-purisme en komma-gechicaneer. Zo kwam mijn code-fetisjisme aan het licht, en schreven wij in ons laatste studiejaar gedrieënlijk de enorm ondergewaardeerde, helaas nimmer uitgebrachte instant nummer 1-hit ‘schone code’. Op jammerlijke wijze is de tekst ervan nooit bewaard gebleven – of is nooit af geschreven, dat blijkt niet langer uit de annalen – maar mijn passie en liefde voor kwaliteit en efficiëntie van code is altijd gebleven.