Kirjautuminen

Haku

Tehtävät

Keskustelu: Yleinen keskustelu: Muuttujien nimeäminen

Sivun loppuun

dazwee [08.11.2013 13:31:16]

#

Moi,

Millaisia nimeämis käytäntöjä teillä on muuttujille?

Olen nähnyt ainakin näitä, esimerkissä VB.net muuttujia, mutta tämä taitaa koskea vähän kaikkia kieliä.

dim _Muuttuja as integer
dim Muuttuja as integer
dim m_Muuttuja as integer
dim intMuuttuja as integer

Milloin kannattaa käyttää tuollaisia nimeämismenetelmiä?

Grez [08.11.2013 13:37:33]

#

Viimeistä (unkarilaista notaatiota) en kyllä nykyisillä työkaluilla käyttäisi. Muuttujan tyypin saa selville yleensä viemällä hiiren siihen päälle jos sitä ei tosiaan muuten muista :D

Nimeämiskäytännöt vaihtuvat vähän kielittäin. Esimerkiksi VB.Netissä muuttujat taitaa olla (oletuksena?) case-insensitive, eli yleinen tapa erotella esimerkiksi paikallisia ja luokan muuttujia isolla tai pienellä alkukirjaimella ei onnistu.

The Alchemist [08.11.2013 13:43:29]

#

Visual basicciin en ota kantaa, mutta yleensä c++:n kanssa nimeämisellä halutaan erottaa luokan jäsenmuuttujat muista muuttujista. Silloin käytetään jotain noista kolmesta ensimmäisestä nimeämistyylistä. (Paitsi että muuttujanimet aloitetaan aina pienellä alkukirjaimella.)

Jotkut käyttävät etuliitettä 'm_', missä m-kirjain tietysti merkitsee memberiä eli jäsentä eli jäsenmuuttujaa. Toisaalta se m-kirjain on aivan turha, koska pelkällä alaviivallakin asia tulee selväksi.

Muita syitä tietysti voi olla staattisten muuttujien ja "yksityisten" jäsenten erottelu. Esimerkiksi pythonissa kaikki luokan jäsenet ovat julkisia, joten yksityisiksi tarkoitetut jäsenet merkitään kahdella alaviivalla (__member).

Metabolix [08.11.2013 16:23:11]

#

Tietääkseni ei ole osoitettu, että mikään tietty lisämerkkien tai isojen kirjainten käyttötapa olisi muita tapoja parempi. Sen sijaan yleensä uskotaan, että yhdessä projektissa kannattaa noudattaa jotain yhtenäistä käytäntöä. Hyvä käytäntö riippuu kielestä ja kirjastoista: esimerkiksi VB.NETissä on hyvin laaja standardikirjasto, jossa nimet noudattavat tiettyä kaavaa, joten on loogista jatkaa samalla linjalla.

Tärkeintä on, että nimi on lähtökohtaisesti järkevä: esimerkiksi Muuttuja ei ole hyvä nimi, kun taas Summa voi tietyssä tilanteessa olla melko hyvä nimi ja LaskunLoppusumma joskus vielä paljon parempi.

Itse en pidä ylimääräisistä merkeistä nimissä, jos niistä ei ole selvää hyötyä. VB.NETissä luokan yksityinen jäsen on jo merkitty sanalla Private, joten m_-etuliite ei tuo mitään lisätietoa. Sen sijaan Pythonissa ei ole sanaa Private, joten on ollut aihetta sopia, että sen sijasta käytetään alaviivoja.

The Alchemist [08.11.2013 16:33:22]

#

Ei kai m_-etuliitteellä aina tarkoiteta yksityistä muuttujaa vaan ihan yleisesti vain jäsentä. Esimerkiksi c++ sallii viitata jäsenmuuttujiin kahdella eri notaatiolla: 'this->x = 2' ja 'x = 2'. Jostain syystä - kenties historiallisista syistä - jälkimmäinen on edelleen hyvin suosittu tapa. Silloin on kohtalaisen suuri vaara, että jäsenmuuttujat ja paikalliset muuttujat menevät sekaisin, jos jäsenmuuttujia ei nimettäisi erikoisesti.

Metabolix [08.11.2013 17:14:42]

#

Enpä muista juurikaan nähneeni julkisia jäseniä, joissa olisi tuollainen etuliite. Muistatko itse? Etuliitteen suosijat taitavat olla samaa joukkoa kuin ne, joiden mielestä julkisia jäsenmuuttujia ei saa käyttää.

Minusta tuollainen muuttujien sekaisin meneminen on aika huono perustelu. Miksei saman tien merkitä funktion parametreja p-kirjaimella ja funktion koodilohkon muuttujia f-kirjaimella ja vaikka while-silmukan sisällä olevia w-kirjaimella? Kai nyt jokaisen pitäisi koodatessaan ymmärtää, mitä eri muuttujat merkitsevät, ja sillä perusteella tietää, ovatko ne paikallisia vai jäseniä. Eräässä tunnetussa tyylioppaassa kehotetaan myös tekemään niin lyhyitä funktioita ja käyttämään funktiossa niin vähän eri muuttujia, että homma pysyy hanskassa, ja aika vaikea on keksiä järkevää syytä, miksei tähän kannattaisi pyrkiä.

The Alchemist [08.11.2013 18:36:43]

#

No tuon edellisen esimerkkini mukaisesti c++:ssa jäsenet ja staticit ovat siinä mielessä 'maagisia', että ne ovat olemassa luokan funktioiden sisällä vaikkei niitä esitellä missään.

C++ sallii muuttujien piilottaa toisiaan, eli esimerkiksi funktiolla saa olla parametri foo vaikka luokalla on (samassa scopessa) jäsen nimeltään foo, ja siitä saa helposti sopan aikaan. Tai jos luokalla on jäsen bar ja aiot funktion sisällä luoda paikallisen muuttujan bar, mutta "jostain syystä" paikallisen muuttujan esittely jää kirjoittamatta, niin huomaattasi tuletkin muuttaneeksi luokan jäsenmuuttujan arvoa ja sitten debuggaaminen meneekin ylitöiksi.

Muuttujat ja funktiot jakavat saman nimiavaruuden (c++:ssa), joten ei voi olla keskenään samannimisiä jäsenmuuttujia ja -funktioita. Joskus näkee sellaista tyyliä, että getter-funktio on nimeltään ihan vain foo eikä getFoo. Tällöin ainoa vaihtoehto on antaa jäsenelle eri nimi, minkä jälkeen voidaan taas miettiä, miksi osa jäsenistä on korostettu alaviivalla ja osa ei.

Pointti kai on se, että monesti nimeämisillä paikkaillaan kielen suunnitteluvirheitä tai jopa arveluttavia ohjelmointikäytäntöjä. Mielestäni se myös parantaa koodin luettavuutta, että aina kun koodissa vilahtaa foo, niin se tarkoittaa paikallista muuttujaa ja _foo taas tarkoittaa jäsentä. Jos 'foo' olisi vähän milloin mitäkin, niin hutilointivirheitä tulisi enemmän.

Joskus muinoin pythonin kehittäjä kaikessa viisaudessaan päätti, etteivät luokat missään nimessä tarvitse yksityisiä jäseniä. Tämän seurauksenahan python-tulkissa on sellaista purkkaa, että kaikki luokan jäsenet, joiden nimi alkaa kahdella alaviivalla, muutetaan julkiseen apiin muotoon '_Luokka__jäsen'...

class Foo:
    def __bar(self):
        print('Foo::bar!')

foo = Foo()

# Tästä tulee virhe; funktiota ei löydy
foo.__bar()

# Tämä toimii
foo._Foo__bar()

hohoo [09.11.2013 17:55:05]

#

Itse olen saanut semmoisen käsityksen, että C++:ssa alaviivalliset nimet kuuluvat kääntäjän sisäisille funktioille ja muuttujille, tai "intrinsic" funktioille, jotka kääntyvät tiety(i)ksi konekood(e)iksi, esim. __debugbreak() = int 3 = katkaisukohta.


Sivun alkuun

Vastaus

Aihe on jo aika vanha, joten et voi enää vastata siihen.

Tietoa sivustosta