Coding standaard

Bij het programmeren van uitbreidingen op bestaande open-source producten zoals Joomla! en Magento is het van belang de gebruikte coding standaard te volgen. Hierdoor is de uitbreiding niet alleen makkelijk te bij te houden, maar gemakkelijk aan andere programmeurs over te dragen.

Module-matige opbouw

Een goed software pakket is te vergelijken met een containerschip. De kern van het systeem vormt het schip, terwijl uitbreidingen gezien moeten worden als containers. Binnen de scheepvaart gelden regels voor de grootte van een container. Hierdoor zijn alle containers van verschillende leveranciers binnen een schip op elkaar te passen, zodat de laadruimte optimaal wordt benut.

 

Hetzelfde geldt voor een software pakket: Als alle uitbreidingen naadloos op elkaar aansluiten, dan ontstaat er een uiterst efficient systeem dat naar eigen wens in te delen is. Om dit te bereiken moet iedere uitbreiding geheel volgens de standaarden van het gebruikte pakket worden gemaakt.

 

Coding standaarden

Bij het navolgen van een coding standaard moet gedacht worden aan de volgende aspecten:

• Engels: De meeste open-source projecten zijn in het Engels opgebouwd. Dit betekent dat binnen de code de naamgeving van klassen, functies en variabelen altijd gebaseerd is op het Engels. Binnen de uitbreiding moet hiernaast ook de normale naamgeving van het systeem worden toegepast.

   

• Grammatica: Binnen een programmeertaal is naast een verplichte grammatica (zonder welke de code simpelweg niet werkt) ook een "decoratieve" grammatica van toepassing. Deze grammatica varieert van het aantal spaties gebruikt binnen een TAB tot de definitie van waar openende en sluitende haakjes moeten komen te staan. Deze ogenschijnlijk onbelangrijke bepalingen lijken niet essentieel, maar Jira acht dit juist van groot belang: Door de grammaticale richtlijnen van een project te volgen is de code altijd gemakkelijk overdraagbaar en bovendien geschikt voor het uitbrengen onder een open-source licentie.

   

• Think first, write next: Software schrijven is soms gemakkelijk, soms uiterst complex. In de meer complexere situaties is het van belang altijd te kiezen voor de beste oplossing, in plaats van de makkelijke oplossing. Het kiezen van de makkelijkste oplossing kan als effect hebben dat de code in de toekomst volledig herschreven moet worden of zelfs onbruikbaar blijkft. Anticipatie van toekomstige functionaliteit is hier een belangrijk onderdeel. Goede code ontstaat pas uit een goed ontwerp, en dat betekent "eerst denken, dan doen".

   

• Modulair: Wijzigingen die worden gemaakt, moeten later gemakkelijk uit te breiden zijn of juist ongedaan te maken zijn. Dit vereist zorgvuldig gemaakte keuzes en een solide architectuur. Als het gaat om een kort project, dan is het moeilijk om hier rekening mee te houden: Er is extra tijd nodig om flexibiliteit in te bouwen die misschien later niet nodig blijkt - het kan dan handig zijn om juist te kiezen voor een niet-modulaire opbouw. Maar zodra een software-product groeit in complexiteit, is het een wijze strategie om voor een modulaire opbouw te kiezen. Hierbij komen design patterns om de hoek kijken, maar ook kennis van de aanwezige architectuur (Magento events, Joomla plugins).