if (ts.has(t)) {
ts.close();
}ts? Test Storage? Tiny Shrimp? The Store? Hva er ts? Hva er t, og hvorfor sjekker vi om ts har t?
Når vi ser nærmere på koden kan vi finne følgende:
TrainStation ts = city.getClosestTs();Aha, så ts er altså en jernbanestasjon. Nå virker det litt mer fornuftig. Greit nok, la oss se på koden igjen.
if (ts.has(t)) {
ts.close();
}Hva er da t? Kan det være et tog? Kanskje det, men vi må likevel sjekke for å være helt sikre.
Train t = new ElectricTrain();Oisann, her hadde vi et elektrisk tog som arver fra Train! Kanskje man burde ha navngitt det et istedet for t?
Fordelene med forkorting av variabelnavn
- Du sparer horisontal skjermplass
Ja, dette var en veldig skuffende liste. Kanskje du kan tenke deg noen fordeler ved forkorting av variabelnavn? Noen har imidlertid hevdet følgende:
- "Du sparer tid ved å bruke mindre tid på å skrive lange variabelnavn!"
- "Du skriver koden raskere!"
- "Du leser koden raskere!"
Til de sier jeg: BARE TULL!
«Ikke bare sløser du din egen tid, du sløser også bort alle andres tid!»
Er det bortkastet tid å forkorte variabelnavn?
Tro det eller ei, ved å forkorte variabelnavn sløses det bort mye tid. Ikke bare sløser du din egen tid, du sløser også bort alle andres tid!
Årsaken til dette kan være overraskende intuitiv når du begynner å tenke deg om. La oss se litt på forenklet arbeidsflyt med og uten forkorting av variabelnavn.
Arbeidsflyt når du jobber med forkortede variabelnavn:
- Du leser koden.
- Du finner ut hva ts er.
- Du husker at ts er TrainStation.
- Du finner ut hva t er.
- Du husket at t er ElectricTrain.
- Du gjør endringer i koden.
Dette forutsetter at du ikke allerede er veldig godt kjent med koden. Hvis du allerede er det, kan du hoppe over trinn 2 og 4.
Arbeidsflyt når du jobber med beskrivende variabelnavn:
- Du leser koden.
- Du gjør endringer i koden.
Ikke så mange trinn er involvert i arbeidsflyten din i dette tilfellet.
Derfor bruker Nils fortsatt GNU Make
Du holder på et tankekart
I tankene dine må du hele tiden bruke tankekraft på å huske hva de forkortede variabelnavnene er.
Når du leser t, husker du at det representerer et Train-objekt, med ElectricTrain som implementasjon. Hver gang du må huske noe, bruker du mer tid enn de som ikke trenger å lese forkortede variabelnavn.
Ved bruk av lange variabelnavn trenger du ikke å huske at eksempelvis trainStation er en TrainStation.
Hva tar lengst tid å lese og forstå? g.perform() eller greetings.perform()?
Forkorting av én eller to variabelnavn er ikke den verste delen. Det er mye mer kostbart når du må hoppe mellom kodesammenheng. t i vårt tilfelle, som representerer et elektrisk tog, kan i et annet tilfelle være et Test-objekt.
Er det unntak?
Selvsagt! Vi er tross alt ikke roboter.
De fleste av oss har sikkert lært hvor forkortelser kan gjøres uten at det påvirker lesbarheten i det hele tatt. Det kan eksempelvis være bruk av domenespesifikke ord. Utenom det har vi akronymer, som JSON. Koden din hadde nok ikke vært mer leselig hvis du hadde skrevet variabelnavnet JsonObject ut som javaScriptObjectNotationObject!
Eksempelvis vil jeg også påstå at en try-catch med én eller kanskje to linjer godt kan forkortes. Her brukes det ofte e eller ex, noe som er mer eller mindre likt i alle Java-prosjekter som bruker try-catch. Dette gjelder sikkert også flere språk.
try {
// ...
} catch (MyException ex) {
log.error("Huff, noe gikk veldig galt!", ex);
}Kort og godt
Forkortelse av variabelnavn er unødvendig, og krever at de som utvikler bruker hodet mer enn nødvendig. Ikke bare er det en ineffektiv måte å skrive kode på, du kaster bort tiden til hele teamet ditt.
Når det brukes lengre beskrivende variabelnavn slipper man å holde på et mentalt kart av flere variabelnavn:
if (trainStation.has(electricTrain)) {
trainStation.close();
}Ikke bruk hodet på unødvendige ting!
La meg avslutte dette med et fint og relevant sitat fra Robert C. Martin:
"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read, makes it easier to write."
- Robert C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship"
Jeg har sett på min 20 år gamle kode, og gremmes 🙈
Grove variabelnavn, uforståelige kommentarer og milevis med README.TXT. Jeg håper noen kjenner seg igjen.