H10: Codekwaliteit

• ICT
• MBO
• Studiejaar 4

H10: Codekwaliteit

"Always code as if the guy who ends up

maintaining your code will be a violent
psychopath who knows where you live."

Leerdoelen

Aan het einde van deze les weet je:

• Waarom je hoge kwaliteit code zou moeten schrijven.
• Waar je goede kwaliteit code aan kunt herkennen
• Hoe je zelf code kunt schrijven van hoge kwaliteit

Exameneis

Code die netjes in elkaar zit is een eis op het examen!

TODO: dit kan misschien wat concreter gemaakt worden.

Codekwaliteit

Doel

Onderhoudbaarheid

Leesbaarheid

Herbruikbaarheid

Veiligheid

Snelheid

Onderhoudbaar

Je code is te onderhouden door jezelf maar ook vooral door anderen.

Het is makkelijk om aanpassingen te maken aan je code op een enkele plek.

Leesbaarheid

Je code is makkelijk te lezen en begrijpen.

Door jezelf.

Ook door developers die pas net aan een project komen.

Ook door developers die nog relatief nieuw zijn.

Herbruikbaar

Code die je schrijft is inzetbaar voor meerdere doeleinden.

Als een functie voor meerdere dingen gebruikt kan worden doe je dat ook

Veilig

Code heeft validaties op input en is niet vatbaar voor veelvoorkomende veiligsheidsissues.

Snelheid

Je code is niet onnodig traag en verwerkt gegevens op een redelijk tempo zonder onnodige stappen te doen.

Doel

Onderhoudbaarheid

Leesbaarheid

Herbruikbaarheid

Veiligheid

Snelheid

Doel

Onderhoudbaarheid

Leesbaarheid

Herbruikbaarheid

Veiligheid

Snelheid

Welke code is beter onderhoudbaar?

1. 
2. 

Benadruk dat het DRY principe ervoor zorgt dat je dingen niet op meerdere plekken aan hoeft te passen.

Onderhoudbaarheid

Simpele logica

DRY (Don't repeat yourself)

Dingen netjes uitgesplitst in functies of modules

Welke code is beter leesbaar?

1. 
2. 

Benadruk vooral de naamgeving, maar ook de type indicaties.

Wat is dit voor score? Wat doet de bonus?

Beetje veel tekst, maar extra documentatie helpt bij begrijpen wat deze functie doet.

Leesbaarheid

Consistente naamgevingen

Goede indentation

Documentatie of docstrings waar mogelijk

Optionele type definitions waar logisch

Uitvragen waarom dit een slechte functie is op deze manier? Waarom is dit slecht leesbaar?

Uitgebreide docstring maakt duidelijk wat dit voor functie is, maakt informatie beschikbaar in je IDE.

Type definitions maakt het duidelijker welke argumenten geaccepteerd worden en wat er terugkomt

Switch statement maakt het duidelijker wat de opzet is van deze functie

Robuust omgaan met onverwachte input.

Commentje erbij is periodiek ook een goede verduidelijking.

Security

Security

Front-end validaties ook op de backend.

Niet kwetsbaar voor SQL injections.

Meer ...?

Benadruk dat hiermee de kous niet af is op het gebied van veilig programmeren, maar dat dit is waar we ons vandaag op richten.

Injection time!

Injection

username: ' OR 1=1 --

 "SELECT * FROM users WHERE username = '' or 1=1 -- ' AND password = '$password'";

Gebruik prepared statements!

Frontend

Backend

Wat was het probleem met die frontend-backend code?

Backend validaties

In het algemeen:

• Valideer altijd input die je krijgt van de gebruiker.
• De frontend code kan makkelijk worden aangepast, dus vertrouw niets wat van een frontend komt.
  
• Check altijd extra je voorwaarden op de backend!

Dit geldt voor zowel web- als native-applicaties.

Tips & Tricks

• Als je hetzelfde stukje code twee keer aan het schrijven bent (of knippen/plakken) ben je waarschijnlijk verkeerd bezig.
• Bekijk je code na het schrijven eens vanuit het perspectief van een nieuw iemand.
  
•  Kijk ook eens naar de mogelijkheden van automatische tools (linters, static analysis tools, etc) en luister naar je IDE.
  

Weekcheck

Op its learning, onder PRO E+F > WED: Kwaliteit van code

Twee keer drie scriptjes (voor WEB en NATIVE)

De drie scriptjes hebben allemaal hun eigen problemen op gebied van kwaliteit.

Fix ze, en leg uit wat je gefixt hebt.