# 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