Udvikler: Drop de alt for lange navne!
Navngivning af variable og metoder kan være en smertefuld proces, hvor gode intentioner ender med kode, der enten er som at læse 'Krig og Fred' eller monteringsvejledningen til et billigere-end-Ikea-møbel. Altså enten alt for lange eller alt for korte.
Det er især de lange navne, der har fået udvikler Robert Nystrom til i et blogindlæg at lange ud efter programmørernes dårlige navngivningsvaner.
Problemet med alt for lange navne er ifølge Robert Nystrom, at de overskygger, hvad der rent faktisk sker i koden. Når navnet på en variabel eller parameter bliver meget langt og samtidig fodres til metodekald, der er tilsvarende lange, så drukner informationen om, hvad koden gør, i information om parametre og metoder.
Han har derfor opstillet fire regler for at skære ned på længden af navne.
1. Udelad det åbenlyse
Når man koder i typefaste sprog, er man sjældent i tvivl om, hvilken type en variabel er eller kan relativt hurtigt finde frem til det. Derfor er der ingen grund til at benytte sig af den slags notation, der ligner et spøgelse fra de sprog hvor ungarsk notation blev brugt.
Din kode behøver altså ikke indeholde typeangivelser i variabelnavne.
Tilsvarende behøver et metodenavn ikke indeholde de typer, metoden tager som parametre, da det er lettere bare at læse den liste af parametre, der følger lige efter.
2. Udelad det, der ikke er unikt
Navne skal blot være tilstrækkeligt unikke til at sikre, at man kan gennemskue, hvad de bruges til. Det bør ikke være en komplet beskrivelse af deres funktion.
Hvis du skal navngive en henvisning til boss-monstret i dit spil, så er det sikkert ikke nødvendigt at skrive, at der er tale om et monster, eller at bossen optræder i den sidste kamp. Det ville kun være relevant, hvis der var bosser, der ikke var monstre, eller en boss, der ikke optrådte i den sidste kamp.
Som udgangspunkt bør man ifølge Robert Nystrom skære helt ind til benet, og så eventuelt ændre det, hvis man får brug for det senere. De fleste udviklingsværktøjer gør det forholdsvis enkelt at rette.
3. Udelad det, der kan læses af sammenhængen
Et klassisk problem er at navngive variable i en klasse med information, der allerede fremgår af klassens navn.
Da man vil læse navnene i en sammenhæng, så er det ikke nødvendigt at gentage informationen i alle navnene. Helt i den objektorienterede ånd nedarver de deres kontekst, som hjælper med at aflæse dem.
4. Udelad overflødige ord
Den fjerde regel er sådan set blot den generelle version af de første tre, men den henviser også til nogle af de ord, der er almindelige at hægte på navne. Ud over typer, som i den første regel, så kan det være nogle etablerede beskrivelser af funktionalitet, som ikke altid er nødvendige.
Det gælder ord som 'manager', 'handler', 'value', 'data' og flere andre, som bliver overflødige, fordi det giver sig selv, hvad der foregår, når man kan læse koden.
Hvis man vil bruge beskrivende navne, bør man også være nærig med ordene. Kan et ord skæres væk, så bør man gøre det.
Hvad mener du, bliver det for meget af det gode, hvis navnene ikke forklarer, hvad de bliver brugt til, når de dukker op 50 linjer senere? Eller har journalistens brug af danske ord til metoder gjort dig for rasende til at forholde dig til længden af navne?
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
