Hvordan man kan være god til at give meningsfulde navne

Hvorfor meningsfulde navne?

  • Overvej at du navngiver et barn (lyder for let ikke?)
youAreMyKid (), cuteLittleBaby (), shyBaby ()
  • Jeg gætter på, at du vil overveje disse navne.
Der er kun to hårde ting i datalogi: cache-ugyldighed og navngivning af ting - Phil Karlton

Vi har en tendens til at danne identiteter, gemme og hente relaterede oplysninger om steder, menneskers ting, der bygger på deres navne. Tilsvarende findes navne overalt, også i den mindste bit kode, vi skriver. Vi navngiver vores variabler, funktioner, argumenter, klasser og pakker.

Vi navngiver vores kildefiler og de mapper, der indeholder dem. Hvis navnene ikke afslører de rigtige intentioner, er de ikke forskellige og ikke let kan genindvindes læsbarhed af koden falder drastisk. I denne artikel vil jeg prøve at dele mine erfaringer med Clean Code af Robert C Martin. Hvad følger er nogle enkle virkelig gode konventioner til at give korrekte navne i vores kode, så vi undgår forvirrende situationer som hvem var John The Third og hvem var John The Third Junior?

En forskel mellem en smart programmør og en professionel programmør er, at den professionelle forstår, at klarhed er konge. Fagfolk bruger deres kræfter til gode og skriver kode, som andre kan forstå - Robert C. Martin

Brug hensigts-afslørende navne

Navnet på en variabel, funktion eller klasse skal besvare alle de store spørgsmål. Det skal fortælle dig, hvorfor det findes, hvad det gør, og hvordan det bruges. Hvis et navn kræver en kommentar, afslører navnet ikke dets hensigt.

Bad

int d; // forløbet tid i dage
// Navnet d afslører intet

Ren

int elapsedTimeInDays;

Kan du fortælle, hvad er formålet med nedenstående kode? Tænk et øjeblik

def get_them ()
 liste1 = []
 the_list.each do | tl |
   hvis tl [0] == 4
    list1.push (tl)
   ende
 ende
 returliste1
ende

spørgsmål:

1. Hvilke slags ting er der på listen?
2. Hvad er betydningen af ​​den nulstil underskrift af et element på listen?
3. Hvad er betydningen af ​​værdien 4?
4. Hvordan skal jeg bruge listen, der returneres?

Svarene på disse spørgsmål findes ikke i kodeeksemplet, men de kunne have været det.

Undgå desinformation

Programmerere skal undgå at efterlade falske spor, der skjuver betydningen af ​​koden. Brug af inkonsekvente stavemåder er disinformation. Henvis ikke listen over salgsfaktura til salgsfaktura-listen. Brug i stedet bundofsalesinvoice, salesinvoices eller salesinvoicegroup

En yderligere form for desinformation i navne ville være brugen af ​​små og store bogstaver i kombination. Hvis du følger camelCase, skal du gå til camelCase-konvention. men bland ikke og match, dvs. SalesInVoice, SavingAccOunt osv.

Foretag meningsfulde sondringer

Du skal ikke bruge det samme navn til at henvise til to forskellige ting i samme omfang. kan du blive fristet til at ændre et navn på en vilkårlig måde.

Støjord er en meningsløs forskel. Forestil dig for eksempel, at du har en produktklasse. Hvis du har lavet endnu en klasse med et kaldet ProductInfo eller ProductData, har du gjort navnene forskellige uden at gøre dem betyde noget andet. Info og data er utydelige støjord som a, an og.

Skelne navne på en sådan måde, at læseren ved, hvad forskellene tilbyder. moneyAmount kan ikke skelnes fra penge, customerInfo kan ikke skelnes fra kunde, accountData kan ikke skelnes fra konto

Brug udtalte navne

Navne, der let kan udtales, kan nemt genindvindes. Hvis du ikke kan udtale det, kan du ikke diskutere det uden at lyde som en idiot

Sammenligne

klasse DtaRcrd102 {
   privat dato genymdhms;
   privat dato modymdhms;
   privat final String pszqint = ”102”;
   / *… * /
};

til

klasse kunde {
   privat Dato-generationTimestamp;
   privat DatoændringTidsstempel;
   privat final String recordId = ”102”;
};

Brug søgbare navne

Søgning af variabler ved navn i en enorm kodebase er en hyppig ting for programmerere, mens de fejlsøger eller forsøger at spore, hvor al den variabel, klasse eller funktion bruges. Navne med en enkelt bogstav og numeriske konstanter har et særligt problem, idet de ikke er lette at finde på tværs af en tekstdel. Undgå at bruge dem.

Undgå kodninger

Kodning af type eller omfangsinformation i navne tilføjer simpelthen en ekstra byrde ved at dechiffrere den og tilføjer kognitiv friktion i at huske den. Det forekommer næppe rimeligt at kræve, at hver ny medarbejder lærer endnu et kodesprog ud over at lære det (normalt betydelige) kodenavn, som de vil arbejde på.

Undgå unødvendige kodninger af datatyper sammen med variabelnavnet.

String firstNameString; Float vægt Float;

Det er muligvis ikke nødvendigt, hvor det er meget kendt for hele verden, at i en brugersammenhæng vil fornavnet have en række tegn. Det samme gælder for vægt, der er decimal / float.

Undgå mental kortlægning

Samarbejde sker ret ofte, når de forskellige hold bygger separate moduler af det samme produkt. Når en ny eller et andet team læser, skal han / hun ikke behøver at oversætte dine navne mentalt til andre navne, de allerede kender. Dette er et problem med variabler med enkeltbogstaver. Bestemt kan en loop-tæller navngives i eller j eller k (dog aldrig l!), Hvis dens omfang er meget lille, og ingen andre navne kan komme i konflikt med den. Dette skyldes, at disse enkeltbogstavernavne til looptællere er traditionelle.

Bad

placeringer = ['Austin', 'New York', 'San Francisco']
locations.each do | l |
 do_stuff
 #do_some_other_stuff
 # andre ting
 # Vent, hvad skal jeg igen?
 afsendelse (l)
ende

Ren

placeringer = ['Austin', 'New York', 'San Francisco']
location.each do | placering |
 #do_stuff
 #do_some_other_stuff
 # ..
 afsendelse (placering)
ende

Klasse Navne

Klasser og objekter skal have navne på substantiv eller substantivfraser som kunde, WikiPage, konto og adresseparser. Undgå ord som Manager, Processor, Data eller Info i navnet på en klasse. Et klassens navn skal ikke være et verb.

Metode Navne

Metoder skal have verb- eller verbfrase-navne som postInvoice, deleteShipment

Vælg et ord pr. Koncept

Vælg et ord for et abstrakt koncept, og hold dig med det. For eksempel er det forvirrende at have hentet, hentet og få som ækvivalente metoder i forskellige klasser. Hvordan kan du huske, hvilket metodenavn der gælder for hvilken klasse? Funktionsnavne skal stå alene, og de skal være ensartede for at du kan vælge den rigtige metode uden yderligere udforskning.

Bad

user_info
brugerdata
user_record
starts_at
start ved
starttidspunkt

Ren

bruger
start ved

et andet eksempel

dataFetcher () vs dataGetter () vs dataRetrieval ()

Hvis alle tre metoder gør det samme, skal du ikke blande og matche på tværs af kodebasen. Hold i stedet ved en.

Brug løsningsdomænenavne

Husk, at de mennesker, der læser din kode, vil være programmerere. Så gå videre og brug computervidenskab (CS) termer, algoritme navne, mønster navne, matematik termer og så videre.

Det er ikke klogt at trække hvert navn fra problemdomænet, fordi vi ikke ønsker, at vores kolleger skal løbe frem og tilbage til kunden, der spørger, hvad hvert navn betyder, når de allerede kender konceptet med et andet navn.

Navnet AccountVisitor betyder meget for en programmør, der er bekendt med VISITOR-mønsteret.

Brug problem domænenavne

Når der ikke er nogen "programmerer-eese" til det, du laver, skal du bruge navnet fra problemdomænet. I det mindste kan den programmør, der vedligeholder din kode, spørge en domæneekspert, hvad den betyder.

Hvis du mestrer at fjerne duplikering og rette dårlige navne, hævder jeg, at du behersker objektorienteret design - J. B. Rainsberger uddrag fra The Four Elements of Simple Design

Tilføj meningsfuld sammenhæng

Der er et par navne, der er meningsfulde i sig selv - de fleste er det ikke. Forestil dig, at du har variabler, der hedder fornavn, efternavn, gade, husnummer, by, stat og postnummer. Sammenlagt er det temmelig klart, at de danner en adresse. Men hvad nu hvis du bare så, at tilstandsvariablen blev brugt alene i en metode

Du kan tilføje kontekst ved hjælp af præfikser: addrFirstName, addrLastName, addrState osv. En selvfølgelig er en bedre løsning at oprette en klasse med navnet Adresse

At skrive ren kode er en kunst, og det kræver praksis, meget af det.

Konklusion

Det sværeste ved at vælge gode navne er, at det kræver gode beskrivende evner og en fælles kulturel baggrund. Dette er et undervisningsspørgsmål snarere end et teknisk, forretnings- eller ledelsesmæssigt spørgsmål. Ingen er gode til at navngive, især når du skynder dig at overholde fristen.

Folk er også bange for at omdøbe tingene af frygt for, at nogle andre udviklere vil gøre indsigelse. Vi deler ikke denne frygt og finder ud af, at vi faktisk er taknemmelige, når navnene ændres (til det bedre)

Så opsæt din navnekonvention snart, hvis den stadig ikke er på plads, og rens ren kode. Happy Coding!