Naming things

Er zijn een paar gevleugelde uitspraken die ik vaak gebruik op werk (zoals '500 is nooit het goede antwoord') en dit software-cliché is waarschijnlijk de aanvoerder op die lijst:

There are only two hard problems in computer science: naming things, cache invalidation and off-by-one errors.

Vooral omdat het waar is: dingen een naam geven is moeilijk, en zonder namen zijn het eigenlijk alleen maar berekeningen zonder betekenis. Er valt pas geld te verdienen als er betekenis – en dus waarde – aan die getallen zitten.

Maar nu las ik een stukje van ntietz, waarin i signaleert dat beschrijvende namen voor stukken code problematisch zijn. De OrderCreateService maakt waarschijnlijk een order aan, maar zodra hij ook mails gaat sturen naar de klant, moet het dan niet de OrderCreateAndEmailSendService zijn? Succes met overal in je codebase de naam van de service aanpassen.

In plaats daarvan, zegt ntietz, moeten namen vooral leuk zijn (mijn vertaling). Diens belangrijkste punt: namen zijn een manier om identiteit uit te drukken, niet om te beschrijven. Het artikel noemt verder geen voorbeelden, maar in mijn hoofd heb ik nu een service genaamd Truus die de orders aanmaakt. De e-mail? 'O ja, die stuurt Truus.'

Ik denk niet dat ik mijn collega's overtuigd krijg, maar ik vind het een geweldig idee.

Reacties

zylstra.org

In reply to Naming things by Sebastiaan Andeweg Ha! Begin jaren negentig noemden we de mail en maillist server bij mijn studievereniging Bettie. Genoemd naar de band Bettie serveert. Heb je iets om…