Kuinka olla hieno antamalla merkityksellisiä nimiä

Miksi merkitykselliset nimet?

  • Harkitse nimeämässäsi lasta (kuulostaa liian helpolta?)
youAreMyKid (), cuteLittleBaby (), ujoBaby ()
  • Luulet, että haluat harkita näitä nimiä.
Tietotekniikassa on vain kaksi kovaa asiaa: välimuistin mitätöinti ja asioiden nimeäminen - Phil Karlton

Meillä on tapana muodostaa identiteettejä, tallentaa ja hakea liittyviä tietoja paikoista, ihmisten asioista nimiensä perusteella. Samoin nimet ovat kaikkialla, jopa pienimmässä kirjoitetussa koodin bitissä. Nimeämme muuttujamme, funktiot, argumentit, luokat ja paketit.

Nimeämme lähdetiedostot ja niitä sisältävät hakemistot. Jos nimet eivät paljasta oikeita aikomuksia, ne eivät ole selviä eikä niitä ole helppo muistaa, koodin luettavuus heikkenee dramaattisesti. Tässä artikkelissa yritän jakaa Robert C Martinin puhtaan koodin opit. Seuraavaksi esitetään joitain yksinkertaisia ​​todella hyviä tapoja antaa oikeita nimiä koodillemme, jotta vältetään sekava tilanne, kuten kuka oli Johannes Kolmas ja kuka oli John Kolmas Juniori?

Yksi ero älykkään ohjelmoijan ja ammattimaisen ohjelmoijan välillä on, että ammattilainen ymmärtää, että selkeys on kuningas. Ammattilaiset käyttävät voimaansa hyväksi ja kirjoittavat koodin, jonka muut ymmärtävät - Robert C. Martin

Käytä aikomusta paljastavia nimiä

Muuttujan, funktion tai luokan nimen pitäisi vastata kaikkiin isoihin kysymyksiin. Sen pitäisi kertoa miksi se on olemassa, mitä se tekee ja miten sitä käytetään. Jos nimi vaatii kommentin, nimi ei paljasta aikomustaan.

Huono

int d; // kulunut aika päivinä
// Nimi d ei paljasta mitään

Puhdas

int kulunutTimeInDays;

Voitko kertoa, mikä on alla olevan koodin tarkoitus? Ajattele hetki

def get_them ()
 lista1 = []
 the_list.each do | tl |
   jos tl [0] == 4
    list1.push (tl)
   pää
 pää
 paluulista1
pää

kysymykset:

1. Millaisia ​​asioita luettelossa on?
2. Mikä merkitys on n-luettelossa olevan kohteen nolla-alaindeksillä?
3. Mikä on arvon 4 merkitys?
4. Kuinka käyttäisin palautettavaa luetteloa?

Näihin kysymyksiin ei ole vastauksia koodinäytteessä, mutta ne olisivat voineet olla.

Vältä vääriä tietoja

Ohjelmoijien on vältettävä väärien vihjeiden jättämistä, jotka hämärtävät koodin merkityksen. Epäjohdonmukaisten oikeinkirjoitusten käyttäminen on vääriä tietoja, älä viitata myyntilaskujen luetteloa myyntilaskujen luetteloihin. sen sijaan käytä nippu myyntiä laskussa, myyntilaskuissa tai myyntilaskuryhmässä

Vielä yksi nimien vääristymien muoto olisi pienten ja isojen kirjaimien yhdistelmä. Jos noudatat camelCase mennä camelCase -käytäntöä. mutta älä sekoita toisiaan, ts. SalesInVoice, SavingAccOunt jne.

Tee merkityksellisiä eroja

Sinun ei pitäisi käyttää samaa nimeä viittaamaan kahteen eri asiaan samassa laajuudessa. saatat olla houkutus muuttaa nimeä mielivaltaisella tavalla.

Melusanat ovat merkityksetön ero. Kuvittele esimerkiksi, että sinulla on tuoteryhmä. Jos olet tehnyt yhden luokan nimeltään ProductInfo tai ProductData, olet tehnyt nimet erilaisiksi tekemättä siitä, että ne tarkoittaisivat mitään erilaista. Info ja Data ovat epäselviä kohinasanoja, kuten a, an ja.

Erota nimet siten, että lukija tietää, mitä erot tarjoavat. moneyAmount on erotettavissa rahasta, customerInfo on erottamaton asiakkaasta, accountData on erotettavissa tilistä

Käytä ääntäviä nimiä

Helposti lausettavat nimet ovat helposti luettavissa. Jos et pysty lausumaan sitä, et voi keskustella siitä kuulostamatta idiootilta

Vertailla

luokka DtaRcrd102 {
   yksityinen päivämäärä genymdhms;
   yksityiset päivämäärämuodot;
   yksityinen lopullinen merkkijono pszqint = ”102”;
   / *… * /
};

että

luokan asiakas {
   yksityinen päivämäärä sukupolven aikaleima;
   yksityinen PäivämäärämuutosTimestamp;
   yksityinen lopullinen merkkijono recordId = ”102”;
};

Käytä haettavia nimiä

Muuttujien etsiminen nimen perusteella valtavasta koodikannasta on usein ohjelmoijille, kun he etsivät virheitä tai yrittävät jäljittää, missä kaikkea muuttujaa, luokkaa tai funktiota käytetään. Yksikirjaimisilla nimillä ja numeerisilla vakioilla on erityinen ongelma sikäli, että niitä ei ole helppo löytää koko tekstikokoon. Vältä niiden käyttöä.

Vältä koodauksia

Tyyppi- tai laajuustietojen koodaaminen nimiksi lisää vain ylimääräisen taakan niiden purkamiseen ja lisää kognitiivista kitkaa sen muistamisessa. On tuskin kohtuullista vaatia, että jokainen uusi työntekijä oppii vielä uuden koodauskielen sen (yleensä huomattavan) koodikoodin oppimisen lisäksi, jossa he työskentelevät.

Vältä tarpeettomia tietotyyppien koodauksia muuttujan nimen kanssa.

Merkkijono firstNameString; Kelluva paino;

Se ei välttämättä ole tarpeen, jos koko maailmalle on hyvin tiedossa, että käyttäjän yhteydessä etunimessä on merkistö. Sama pätee painoon, joka on desimaali / kelluva.

Vältä mielenkartoitusta

Yhteistyötä tapahtuu melko usein, kun eri joukkueet rakentavat saman tuotteen erillisiä moduuleja. Kun joku uusi tai muusta joukkueesta lukee, hänen ei tarvitse joutua henkisesti kääntämään nimesi muihin nimiin, jotka he jo tietävät. Tämä on ongelma yksikirjaimisten muuttujien nimissä. Varmasti silmukkalaskurin nimi voi olla i tai j tai k (tosin koskaan l!), Jos sen laajuus on hyvin pieni eikä mikään muu nimi voi olla ristiriidassa sen kanssa. Tämä johtuu siitä, että silmukkalaskurien yksikirjaimiset nimet ovat perinteisiä.

Huono

paikat = ['Austin', 'New York', 'San Francisco']
Locations.each do | l |
 tehdä asioita
 #do_some_other_stuff
 # muu tavara
 # Odota, mitä `l` tarkoittaa jälleen?
 lähettäminen (l)
pää

Puhdas

paikat = ['Austin', 'New York', 'San Francisco']
sijainnit.kaikkia | sijainti |
 #tehdä asioita
 #do_some_other_stuff
 # ..
 lähettäminen (paikka)
pää

Luokan nimet

Luokilla ja objekteilla tulisi olla substantiivi- tai substantiivilausekkeita, kuten Asiakas, WikiPage, Tili ja AddressParser. Vältä luokan nimissä sanoja, kuten Manager, Processor, Data tai Info. Luokan nimen ei pitäisi olla verbi.

Menetelmän nimet

Menetelmillä tulisi olla verbi- tai verbilauseenimet, kuten postInvoice, deleteShipment

Valitse yksi sana per konsepti

Valitse yksi sana yhdestä abstraktista käsitteestä ja pysy siinä. Esimerkiksi on hämmentävää hakea, hakea ja saada vastaavina menetelminä eri luokissa. Kuinka muistat, minkä menetelmän nimi menee luokan kanssa? Funktionimien on oltava itsenäisiä, ja niiden on oltava yhdenmukaisia, jotta valitset oikean menetelmän ilman ylimääräisiä tutkimuksia.

Huono

käyttäjätiedot
käyttäjätiedot
user_record
alkaa
aloittaa
aloitusaika

Puhdas

käyttäjä
aloittaa

toinen esimerkki

dataFetcher () vs dataGetter () vs dataRetrieval ()

Jos kaikki kolme menetelmää tekevät saman asian, älä sekoita ja sovi koodikannan välillä. Sen sijaan kiinni yksi.

Käytä ratkaisualueiden nimiä

Muista, että koodisi lukeneet ihmiset ovat ohjelmoijia. Joten mene eteenpäin ja käytä tietotekniikan (CS) termejä, algoritmien nimiä, kuvioiden nimiä, matemaattisia termejä ja niin edelleen.

Ei ole viisasta vetää jokaista nimeä ongelma-alueelta, koska emme halua, että työtovereidemme joudutaan kuljettamaan edestakaisin asiakkaan luo kysyen, mitä jokainen nimi tarkoittaa, kun he tietävät käsitteen toisella nimellä.

Nimi AccountVisitor tarkoittaa paljon ohjelmoijalle, joka tuntee VISITOR-mallin.

Käytä ongelmaalueiden nimiä

Kun tekemällesi ei ole ”ohjelmoijia”, käytä ongelmaalueen nimeä. Ainakin koodiasi ylläpitävä ohjelmoija voi kysyä verkkotunnuksen asiantuntijalta, mitä se tarkoittaa.

Jos hallitset päällekkäisyyksien poistamisen ja huonojen nimien korjaamisen, väitän sinun hallitsevan oliokeskeistä suunnittelua - J. B. Rainsberger ote yksinkertaisen suunnittelun neljästä elementistä

Lisää merkityksellinen konteksti

On muutama nimi, jolla on itsessään merkitystä - useimmat eivät ole. Kuvittele, että sinulla on muuttujia nimeltä eesnimi, sukunimi, katu, talonumero, kaupunki, osavaltio ja postinumero. Yhdessä on melko selvää, että ne muodostavat osoitteen. Mutta entä jos näkisit vain tilamuuttujan käyttävän yksin menetelmässä

Voit lisätä kontekstin etuliitteillä: addrFirstName, addrLastName, addrState ja niin edelleen. Tietenkin, parempi ratkaisu on luoda luokka, jonka nimi on Address

Puhtaan koodin kirjoittaminen on taidetta ja vaatii paljon, sitä harjoittelua.

johtopäätös

Vaikein valinta hyvien nimien valinnassa on se, että se vaatii hyvät kuvailevat taidot ja yhteisen kulttuuritaustan. Tämä on pikemminkin opetuskysymys kuin tekninen, liiketoimintaa tai johtamista koskeva kysymys. Kukaan ei osaa nimetä varsinkaan, kun kiireet noudattaa määräaikaa.

Ihmiset pelkäävät myös asioiden uudelleennimeämistä pelkääessään, että jotkut muut kehittäjät vastustavat sitä. Emme jaa tätä pelkoa ja löydämme, että olemme todella kiitollisia, kun nimet vaihtuvat (parempaan suuntaan)

Joten määritä nimeämiskäytäntösi pian, jos se ei vielä ole paikallaan, ja murskaa puhdas koodi. Hyvää koodausta!