---
# System prepended metadata

title: Development Guidelines

---

# Development Guidelines
- Lastig om code te moeten refactoren

### Code schrijven
- Linter / prettier
    - Linter on save -> hele kleine aanpassing kan hele grote MR opleveren
    - Losse commits? (1 functioneel / 1 met linting)
    - Pijn van in 1x zit in openstaande branches
    - ! Maar toch voorkeur voor datum prikken & maar doen -> actiepunt in plan (na ook opruimen van openstaande MR's)
    - Davey heeft linter-config WIP
    - Gedeelde voor alle typescript in monorepo

- Code schrijven
    - Naamgeving
        - Op letten bij reviewen!
        - Groote van context bepaalt noodzaak voor goede naam (voor tussenvariablen -> 1x gebruiken: naam niet zo boeiend)
        - Kotlin/Java: globale variabelen beginnen met m_? -> we hebben moderne IDE's.
    - Duidelijkheid voor LOC-count
        - Ook al fijn tijdens pair-programmen
        - Bij lezen het idee 'dit is magie' -> goeie reden om anders te schrijven (/ review-opmerking te plaatsen)
        - Lagere standaard voor front-end, is dat erg?
        - (onthouden) voorkomen dynamische indexing tenzij goed getyped
    - Plattere code = fijn (weinig geneste if/elses) (-> voorbeeld Davey, zit in Linter)

- Testen
    - Nieuwe test hoeft niet veel moeite te kosten
        - Mits code zo in elkaar zit dat DB's e.d. makkelijk te mocken zijn (?)
    - Belangrijk(ste?) doel -> garantie houden dat bestaande functionaliteiten niet kapot gaan
    - Front-end ook belangrijk (bv tours ineens stuk)
        - Wel lastig -> veel afhankelijk van aanwezigheid data
        - Research nodig
    - Onderhoud belangrijk -> verkeerd gestubde DB zorgde voor totaal niet draaien van een set unit-tests
    - Consensus: Meer induiken & prio geven

- Documenteren
    - In code:
        - Comments op functionaliteit wanneer die niet vanzelfsprekend/makkelijk te lezen
        - Python: docstrings (tussen functienaam & -body), bevalt goed
        - Inline comments (in functieblokken) maakt lezen lastiger -> gebruiken als goeie indicatie van waar splitsen in kleinere functies/files
    - Algemeen (voor nieuwe devs -> readme oid)
        - API-achtige documentatie (wel automatisch te genereren) & user-guide documentatie (niet)
        - Lastig om up-to-date te houden
        - Flow-charts (zeker van core-functionaliteit) zijn wel nice
            - Praktijk: wordt niet geupdate na aanpassing notificatie-systeem
            - Automatisch genereerbaar?

- Mergen
    - Groter project: Opsplitsen in losse feature-branches met eigen MR's naar hoofd-project-branch
    - Snel branch live zetten zou handig zijn (@Marciano?)

- Reviewen
    - Meer ogen is meer beter (1 minimum, maar 2 misschien fijner?)
    - Hindernis: switchen naar branch om te reviewen is duur (stashen/bouwen/draaien) -> hangt samen met makkelijk branch opspinnen


