Voorwoord

Doel

Dit document is geschreven met als doel alle bindende coding guidelines waaraan elk lid van BitHopper zicht dient te houden vast te leggen. In het geval dat er twijfel is binnen het team kan dit document geraadpleegd worden om zonder discussie conflicten op te lossen. Elk teamlid, zoals benoemd op het voorblad dient dit document dan ook als leidende dan wel bindende documentatie te beschouwen omtrent de coding guidelines binnen het team.

Aanpassingen

BitHopper behoudt zich het recht voor ten alle tijden aanpassingen te maken aan dit document. Dit dient echter wel te gebeuren in strict overleg met het gehele team. Alle aanpassingen dienen uitgebreid en correct gedocumenteerd te worden in de documentgeschiedenis conform het volgende format:

Versienummer: voor tussentijdse aanpassingen dient enkel het getal achter de punt verhoogd te worden met één per aanpassing sessie. Voor een gefinaliseerde nieuwe versie dient het getal voor de punt verhoogd te worden met één en dient het getal achter de punt teruggebracht te worden naar nul.

Datum: De datum en tijd waarop de aanpassingen doorgevoerd zijn volgens het format dd-mm-jjjj.

Naam Bewerker(s): De voor- en achternaam/achternamen van het teamlid dat de aanpassingen doorgevoerd heeft.

Updates: Zo uitgebreid mogelijke, compact geformuleerde opsomming van alle aanpassingen die doorgevoerd zijn.

Een aanpassing sessie komt ten einde wanneer er langer dan vijftien minuten niet gewerkt is aan dit document door een teamlid of wanneer het tijdstip 00:00 bereikt wordt. Voor elke aanpassing sessie dient een nieuwe rij in de documentgeschiedenis aangemaakt te worden.

Guidelines

Algemene Reglementen

• Alle code dient Object Oriented te zijn.
• Een methode dient nooit meer dan één taak uit te voeren.
• Een methode dient nooit een parameter mee te krijgen die niet gebruikt wordt binnen de methode.
• Een methode dient niet langer te zijn dan absoluut nodig om zijn enige taak succesvol uit te voeren.
• Een try-catch statement dient nooit een lege catch-branch te hebben.
• Waarnodig moeten klassen, instance variabelen en methoden voorzien te worden van functie definiërend commentaar.
• Alle code dient altijd in correct consistent Engels geschreven te zijn.
• Commentaar dient altijd in correct consistent Engels geschreven te zijn. Het correct gebruik van leestekens is ook onder dit reglement verplicht.
• Een klasse dient geen instance variabelen te hebben die niet gebruikt worden.
• Alle klasse-, property- en methodenamen dienen geschreven te worden in Pascal Casing waarbij de het eerste karakter van de naam uppercase is.
• Alle variabelenamen en fields dienen geschreven te worden in Camel Casing.
• Het gebruik van numerieke karakters is sterk afgeraden.

Code formatting

Ieder Teamlid dient zicht te houden aan de volgende guidelines omtrent de formatting van code:

• Switch statement: (Het gebruik van een default-statement is echter wel altijd optioneel.)

switch (variabele)
{
case condition1:
    //code
    break;
case condition2:
    //code
    break;
default:
    //code
    break;
}

• If statement:

if (conditie)
{
    //code
}

• Indien de code slechts één regel bevat:

if (conditie)
    //code

• For loop

for(type variabele = value; conditie; iteratie)
{
    //code
}

• Foreach loop

foreach(type variabele in collectie)
{
    //code
}

• While loop

while(conditie)
{
    //code
}

GitHub Gebruik

• Commentaar etc. dient altijd in consistent, correct Engels geschreven te zijn. Het gebruik van leestekens is hierbij inbegrepen.
• Elk stuk functionaliteit dient enkel gebouwd te worden in een eigen branche die gebaseerd is op de ‘development’ branch.
• Het is toegestaan, maar niet aangeraden om code te committen die zich niet in een functionele toestand bevindt.
• Een commit dient altijd van een titel en consistent, beschrijvend commentaar voorzien te zijn.
• Het is niet toegestaan een pull-request te openen als de gebouwde functionaliteit in de bijbehorende branche niet functioneel is.
• Een pull-request dient niet langer dan 24 uur open te staan.
• Een pull-request dient niet zomaar geaccepteerd te worden zonder dat de gebouwde functionaliteit door een ander teamlid gereviewed is.
• Een pull-request dient enkel geaccepteerd te worden indien de gebouwde functionaliteit functioneel is.
• Een pull-request dient niet zonder opgave van reden te worden geweigerd.
• Een geweigerd pull-request dient niet zomaar heropend te worden zonder dat de vereiste aanpassingen verricht zijn.
• Een pull-request mag enkel geopend worden wanneer er geen merge conflicten meer zijn.
• Merges naar de master branch dienen enkel uitgevoerd te worden door de configuratiebeheerder.