…meie igapäevast IT’d anna meile igapäev…

2008-04-29

Muutujate nimetamine: kõige raskem osa programmeerimisest?

Filed under: Programmeerimine — Sander @ 10:06:22

Ühes hiljutises postituses õudsa koodi kohta olid muutujad:

par1 as integer,par2 as string,par3 as string,par4 as string,
par5 as integer,par6 as string, par7 as string,par8 as datetime,
par9 as integer,par10 as string,par11 as integer,par12 as string,
par13 as string,par14 as integer,par15 as string,par16 as integer,
par17 as integer,par18 as integer,par19 as integer

Selliselt nimetatud muutujaid ilmselgelt ei ole… mitte just kõige paremad kasutada. Kas par7 on string mille sees kasutaja nimi või on see DateTime tänase kuupäevaga? Kas par19 on tellimuses olevate esemete arv või on see par18 ja par19 on hoopiski allahindluse protsent?

Koodi lugemine on raskem, kui koodi kirjutamine. Samas ei pruugi see nii olla, muutujate korralik nimetamine on üks neid asju, mis koodist arusaamist oluliselt parandavad.

Teooriaid muutujate nimetamise kohta on palju – kuid ühes on nad kõik ühel meelel: muutuja nimi peab olema selline, mis seda programmeerija jaoks selgelt teistest muutujatest eristab. Olen ise ka paar koodimisstandardit kirjutanud ja sel teemal üsna palju mõtisklenud. Ilmselt pean siinkohal taas lisama disclaimeri, et siinne tekst sisaldab minu mõtteid, mis ei pretendeeri absoluutseks tõeks olemisele. Ehk teisisõnu, ärge liiga valusalt lööge…

Samuti on see jutt kindlasti programmeerimiskeelte kohta, mida ise rohkem kasutan – ehk eelkõige C#, vähem teisi (JavaScript, C/C++, Delphi, PHP jt). Eri keeltel on eri koodimisstandadid, eriti kui keelte erinevus on radikaalne (deklaratiivsed keeled nagu SQL ja LINQ, protseduraalsed (imperatiivsed) C++/C#/Java, funktsionaalsed Haskell ja Lisp – ei saa kõik jagada sama koodistruktuuri ja -standardit. Live with it or die trying!). Mõned põhitõed on aga universaalsed.

  • Muutuja või protseduuri nimi peab sisaldama vastavalt kas sisu või tegevust kirjeldavat infot (intention-revealing names). Maailma kõige halvem muutujanimi on data, sellele järgnevad data2 ja x. Sa ei tea, mis on data sees peituvad andmed. See ei kirjelda midagi, sest – üllatus-üllatus – kõik muutujad sisaldavad mingeid andmeid. Seetõttu, mitte data vaid personFullName, itemCount, getNumberOfItems(). Uuringute järgi on ideaalne muutujanimi 10..16 tähemärki (Gorla, Benander, Benander 1990), selle korral on debugimine kiirem ja koodist arusaamine parim. Karta ei maksa ka liigset trükkimist, IntelliSense ja selle analoogid on tänapäeval pea kõigis keskkondades olemas.
  • Ära mängi asjatult suur- ja väiketähtedega, kasuta alati ühte ja sama standardit, olgu see camelCase, PascalCase või mõni muu. Sa tõesti ei taha olukorda, kus:
    one = 1;
    One = 2; 
    oNe = "2008-04-29"; 
    onE = 3.1415; 
    ONe = 0x80F; 
    oNE = '1'; 
    OnE = WM_CLOSE; 
    ONE = 0;
    

    Kasuta sellist stiili, mis maksimeerib loetavust. Alakriipsude kasutamine ei ole enamasti soovitav, kuna FirstName ja First_name on sama hästi loetavad, kuid esimene on lühem ja mugavam kirjutada. Samuti kasutatakse alakriipsu muude asjade tähistamiseks, sellest allpool.

  • Eesliide. Täielik Hungarian notation on moodsates/uuemates programmeerimiskeeltes mittesoovitatav (rgszxyzpdqOrderNo küll kirjeldab täielikult muutuja OrderNo tüüpi, aga lihtsam on otsida üles selle muutuja deklaratsioon, kui mõistatada, mida rgszxyzpdq tähendab). Lihtsa andmetüübi põhised eesliidesed (prefix notation) on lihtsad ja mugavad kasutada: i on integer (iAmount), s on string (sFullName), d on double (dDiscountPercent) jne. Samamoodi on ka kasutajaliidese elementide tähistamiseks lihtsad kahe- või kolmetähelised eesliidesed: lb on label (lbHeader), ed on kõik edit-tüüpi elemendid (edName), mnu on menüü, mni on menuitem jne. Loomulikult on need keelepõhised ja tuleb firmas/tiimis/projektis kokku leppida, mitte sundida peale SQL reegleid Java-programmeerijatele. Kasutatakse ka järelliidet: startPoint, endPoint, fullDataRow, nameEdit jne. Ise nende suur fänn ei ole, kuid teatud kohtades olen kasutanud. Nii ees- kui ka järelliite kasutamine ei peaks olema alati kohustuslik muutujate puhul.
  • Semantilised eesliited (semantic prefixes, ka osaliselt Apps Hungarian) kirjeldavad muutuja kasutusala. Näiteks c on count (cItems), first/last (firstItem), d difference jne. Enamasti neid teadlikult ei kasutata ega standarditesse sisse ei kirjutata. Ei soovita kasutada, aga ära peab nad mainima.
  • Omaette teema on skoobipõhised semantilised eesliidesed, so g_ globaalse ja m_ privaatse klassimuutuja nimes (ka s_ staatilise muutuja märkimiseks). Microsoft on ametlikult soovitanud mitte m_ stiili kasutada, vaid kasutada ainult alakriipsu _ – so, mitte m_muutuja, vaid _muutuja. Samas on MS enda koodis mõlemat näha. Ise kipun eelistama ainult alakriipsu – lühem – või isegi private/protected muutujaid nimeliselt mitte eristama avalikest. Viimane on kindlasti paha praktika, üritan ennast parandada.
  • Ajutised muutujad, kus “mitmesugust” infot hoitakse: tüübi eesliide + Tmp, näiteks sTmp, iTmp. Selliste muutujate kasutamine reeglina ei ole hea idee, sest see võib põhjustada väga halvasti leitavaid vigasid – näiteks on sTmp’i pandud eelnevalt kasutaja nimi, kuid siis omistatakse sellele tekstboxi tekstina sisestatud number, et konvertida see reaalseks arvuks. Kui aga mingil põhjusel jääb sinna muutujasse kasutaja nimi, siis saadakse aga loomulikult viga – kuid vea põhjus ei pruugi üldsegi nii lihtsalt leitav olla.
  • Tsüklimuutujad (loop iterators): i, j, k. Need on nõnda nimetatud ajaloolistel põhjustel – Fortranis on I, J, K, L, M ja N automaatselt deklareeritud integerideks. Kui aga iteraatorit kasutatakse ka väljaspool tsüklit või tegemist on pikemate tsüklitega – kasuta pikemat, selgemat nime. See võimaldab vältida olukorda, kus i ja j segamini lähevad jms. Kindlasti ära kasuta i, ii, iii.
  • Väldi täpitähti. Isegi täis-Unicode keskkonnas võib esineda üliootamatuid muudatusi – omal on kogemus, kus eestlasest arendaja tegi rõõmsalt õöäü’dega muutujanimesid, kuid sama kood venelasest arendaja venekeelse Windowsiga kaotas täpitähed muutujanimedest ära…
  • Kasuta hääldatavaid nimesid! Mitte dtwhnItmArrived vaid ItemArrivalDate. Esiteks saad sa kaasprogrammeerijatega normaalselt kõneleda ja teiseks on kirjavead paremini näha (võrdle: dtwhItmArrived vs dtwhnItmArrived ja ItemArivalDate vs ItemArrivalDate). Rääkimata sellest, et lihtsam on aru saada.

 

Mõned kasulikud lingid

 

Ah jaa, pealkirjast. Vähemalt osa programmeerijate jaoks tundub puhta, kommenteeritud ja hästi loetava koodi kirjutamine olema kõige suurem probleem koodimisel. Ilmselt on see nagu lõpukirjandiga – mõnele inimesele oli see nuusata, samas kui teiste jaoks oli see lõputu õudus.

About these ads

3 kommentaari »

  1. Tüübipõhise “Ungari notatsiooni” suremise vastu poleks mul küll mitte midagi, kaasaegsetes keeltes vähemasti… Nende programmeerimisamishite suhtes, kes seda veel kasutavad, tuleb olla ettevaatlik ja alati uurida, kuidas nad suhtuvad teistesse moodsatesse komponentidesse nagu prügikoristaja ja geneerikud… Senised kogemused näitavad, et üldiselt halvasti :P

    kommentaar kirjutas Ray D. Noper — 2008-04-29 @ 10:52:41 | Vasta

  2. Väike parandus – Lisp ei ole ainult funktsionaalne keel – sellega saab programmeerida ka imperatiivselt ja/või objekt-orienteeritult. (http://en.wikipedia.org/wiki/LISP)

    kommentaar kirjutas Lauri — 2008-04-29 @ 14:37:28 | Vasta

  3. […] Filed under: Programmeerimine — dukelupus @ 12:03:10 Kui eelmine post oli muutujate nimetamisest, siis seekord tuleb veidi juttu […]

    Pingback-viide kirjutas Veel raskeid asju programmeerimisel: kommentaarid « …meie igapäevast IT’d anna meile igapäev… — 2008-04-30 @ 12:04:12 | Vasta


Selle postituse kommentaaride RSS-voog. TrackBack URI

Lisa kommentaar

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Muuda )

Twitter picture

You are commenting using your Twitter account. Log Out / Muuda )

Facebook photo

You are commenting using your Facebook account. Log Out / Muuda )

Google+ photo

You are commenting using your Google+ account. Log Out / Muuda )

Connecting to %s

Theme: Rubric. Get a free blog at WordPress.com

Follow

Get every new post delivered to your Inbox.

Join 83 other followers