Clean Code : Naamgeving

Afgelopen tijd ben ik druk bezig geweest om de manier van werken binnen mijn bedrijf JWE new media solutions zo optimaal mogelijk te maken. Eén van de belangrijke items hierbij is altijd het optimaliseren van broncode om deze zo goed mogelijk leesbaar te maken. In de komende blogposts ga ik proberen hier meer informatie over te geven.

Naamgeving
Een belangrijk onderdeel dat tijdens het programmeren (in alle talen) terugkeert, is het geven van namen aan functies, variabelen, argumenten, classes en andere elementen.

Het geven van namen dient aan een aantal belangrijke voorwaarden te voldoen:

  • Ze moeten relevant zijn
  • Commentaar dient overbodig te zijn
  • Functienamen bevatten (vrijwel altijd) een werkwoord
  • Namen moeten voorspelbaar zijn
  • Namen moeten makkelijk te vinden zijn (dit doe je door ze bijvoorbeeld voorspelbaar te maken)

Relevantie
Als we kijken naar het onderstaande stukje broncode van de class BankAccount dan zien we dat er 2 variabelen worden gedeclareerd met verschillende namen. Beide variabelen dienen hetzelfde doel; ze bevatten namelijk het bedrag op de rekening.

Bank Account
De naam $b vertelt niks over de betekenis en is dus niet relevant, er is zelfs commentaar nodig om de betekenis van de variabele te kunnen (her)kennen. De naam $balance is daarentegen wel goed gekozen. Duidelijk is namelijk direct wat het inhoudt nl.; het saldo van de betreffende bankrekening.

Duidelijkheid
Namen moeten niet alleen relevant zijn maar ook duidelijk. Als je kijkt naar de parameters in onderstaande functie en de naam van deze functie zul je zien dat deze vrij onduidelijk zijn.

Functie fout

Beter zou het zijn om de functie te definiëren met duidelijke en heldere parameters en een betere naam voor de functie zoals in het onderstaande voorbeeld.

Functie goed
Ruis voorkomen
Eén van de zaken die naast relevantie en duidelijkheid oorzaak is voor onbegrijpelijke broncode is ruis. Een voorbeeld hiervan is bijvoorbeeld een class met de naam ProductInfo of ProductData. Deze namen kunnen beiden hetzelfde betekenen en veroorzaken dus ruis bij het lezen van de broncode. Andere voorbeelden zijn bijvoorbeeld de namen ProductObject, moneyAmount of nameString.

Voorspelbaarheid en vindbaarheid
Deze 2 voorwaarden voor namen van classes, functies, variabelen of parameters zijn eigenlijk logisch. Immers als je in de broncode van iemand moet zoeken naar een bepaalde functie of variabelen is het handig als deze voorspelbaar is. Hierdoor wordt de vindbaarheid dus automatisch verbeterd. Een naam Customer zal eerder gevonden worden als een programmeur zoekt naar de functionaliteiten van een klant dan de naam CtrMr of een andere verbastering. Zorg dus dat namen voorspelbaar zijn en hierdoor vindbaar zijn.

Geen reacties.

Reageer