Keskustelu: Ohjelmointikysymykset: C++, PHP: Oikeat nimeämiskäytännöt

Kommentoin tätä koodivinkkiä, jossa käytetään suomen kieltä ja pieniä kirjaimia nimissä.

Suosittelen vielä opettelemaan nimeämiset heti alkumetreillä.
Kun opettelee jonkun asian alusta alkaen väärin siitä tavasta on vaikea päästä eroon!

Toinen asia on unohtaa suomenkieli, sitä käytetään kuitenkin vähemmän kun toista kotimaista.
Luokkakin näyttää siistimmältä

class CSomeClass{
private:
   int iValue;

public:
   int  GetValue(void);
   void SetValue(int iNewValue);
};

Jos olet sitä mieltä, että esimerkiksi C++:n kehittäjät ovat nimenneet standardikirjaston luokat ja muuttujat "amatöörimaisesti", kehottaisin harkitsemaan uudelleen, heillä kun on varmaankin asiasta enemmän kokemusta kuin sinulla. En muista nähneeni siellä tuollaisia kammotuksia kuin iNewValue, muistatko itse?

Kun et pysty kuitenkaan pätevästi perustelemaan, miksi nimeäminen pitäisi tehdä noin ja millä tavalla muu nimeäminen on tehty "väärin", voisit ehkä harkita olevasi asiasta aivan hiljaa. Kukaan ei kiellä sinua kirjoittamasta koodiasi noin sekavasti isolla ja ilman sanavälejä, mutta henkilökohtaisesti luen mieluummin pitkiä_nimiä_joissa_on_selvät_välit kuin Pitki­ä­Nimiä­Joiden­Välien­Paikat­Eivät­Ole­Lain­kaan­Niin­Selviä puhumattakaan, että haluaisin muistella, oliko jokin muuttuja nyt lPituus vai iPituus vai ehkä jopa fPituus, kun pääasia on, että se on pituus. Jos vielä haluat itse ohjelmoida englanniksi, saat toki niin tehdä, mutta tämä on kuitenkin suomenkielinen sivusto, mikä jo sinänsä riittää syyksi käyttää suomea myös tänne lähetettävien koodien kielenä.

Jos itse olet niin lukkiutunut yhteen koodinkirjoitustapaan, ettet kykene tarvittaessa kirjoittamaan toisella tavalla, ihmettelen, jos et jossain vaiheessa työelämää ole ongelmissa tuon kanssa (jos nyt edes alan töitä teet?), nimittäin ainakaan omalla työpaikallani nimeämiskäytäntö ei ole sen paremmin tuollainen kuin sellainenkaan, kuin minulla on omissa projekteissani.

Itse voisit sen sijaan opetella irti tuollaisista pahoista tavoista kuin void-sanan käyttö tyhjän parametrilistan merkkinä ja private-sanan käyttö luokan alussa. Molemmathan ovat turhia, aivan kuten toisinaan ilmenevä inline sellaisen jäsenfunktion edessä, joka muutenkin on inline-funktio. Ehkäpä ne vain osoittavat, ettet hallitse kieltä riittävästi tietääksesi, ettei noilla ole vaikutusta.

Älä ota tätä kaikkea turhan vakavasti, mutta ole hyvä ja keskity jatkossa asioihin, joilla on oikeasti laadullista tai toiminnallista merkitystä.

Unkarilainen notaatio ?

Huomaan, että osaat koodata.
Taida olla huomattavasti parempi kuin minä.

Mutta et tee sitä duuniksesi.
Itse olen ollut poissa 3 vuotta koodauksesta.
Samoin huomaat, etten laittanut

typedef class{
...
}CSomeClass,*pCSomeClass;

Miksi vedit noin herneen nenään ?

Jos opetat muita käyttämään #ifndef ja #endif
miksi laitat #define MINUNLUOKKA_A jälkeen numeron ?

Eikös se ole turhaa, anna kääntäjän alustaa se haluamallaan numerolla ?

sitä paitsi

class member, int m_iValue;

Sillä on todellakin väliä kuinka nimeät muuttujat,
et tarvitse tyyppimuunnoksia kun näet suoraan muutujan nimestä mitä se edustaa. Englanniksi siksi, että muutkin varatut sanat edustavat englantia, eikä suomea.

Jos teet ison projektin ja sen ostaa koodeineen/docuineen ulkomaalainen yhtiö. Ei sinun tarvitse käydä uudelleen läpi kirjoittamaasi suomenkieltä.

Tietenkin täällä ne edustavat harjoitusta.
Missä suomi on oleellista vaativat sen, ihan johdon mukaisuuden vuoksi.
Esimerkiksi DirX mitä yritän opiskella ja sen docut on eivät ole johdon mukaisia, ne olettaa aivan liikaa.
Jos lataat esmes uusimman dirx_sdk:n se olettaa, että olet lukenut myös aikaisemmat.

Elä hyvä mies ota itseesi, en ole mollaamassa sinua.

Lintu kirjoitti:

Mutta et tee sitä duuniksesi.

Itse asiassa teen, tosin PHP:llä ja JavaScriptilla.

Lintu kirjoitti:

Miksi vedit noin herneen nenään ?

Enkö juuri sanonut, että älä ota turhan vakavasti? Halusin vain huomauttaa, että kommentoit aivan älytöntä asiaa aivan älyttömin perustein. Ilmeisesti retoriikka meni yli.

Lintu kirjoitti:

Eikös se ole turhaa, anna kääntäjän alustaa se haluamallaan numerolla ?

Tarkkaan ottaen kääntäjä ei käsittele esikääntäjän komentoja. Joka tapauksessa jos numeroa ei laita, mitään numeroa ei tule, vaan määrittelystä tulee tyhjä. On totta, että tässä tapauksessa numero ei standardin mukaan olisi tarpeen, mutta jotkin rikkinäiset esikääntäjät kuitenkin tarvitsevat sen (en tähän hätään muista, mitkä täsmälleen).

Varsin helposti saadaan aikaan tilanteita, joissa luokkien funktioita varten tarvitaan toisten luokkien kokonaisia määrittelyjä sellaisella tavalla ristiin, että funktioiden toteuttaminen inline-funktioina vaatii ylimääräisiä kikkoja. Tällöin tuota lukua voi käyttää ilmaisemaan, mitkä asiat luokasta on jo saatu liitettyä. (Esikääntäjätemppuja helpompi ratkaisu on kuitenkin vain jakaa eri vaiheet eri tiedostoihin ja sisällyttää näistä vain tarpeelliset — tai kiertää tilanne jotenkin muuten.)

Lintu kirjoitti:

Sillä on todellakin väliä kuinka nimeät muuttujat, et tarvitse tyyppimuunnoksia kun näet suoraan muutujan nimestä mitä se edustaa.

Näkeehän sen siitä muuttujan määrittelystäkin. Onko jotain suurta merkitystä sillä, pitääkö muistaa "float length" vai "m_fLength"? Ensimmäisessä tapauksessa IDEn täydennystoiminto saattaa näyttää myös tyypin, kun muistaa kirjoittaa edes "length". Jälkimmäisessä tapauksessa se tuskin osaa täydentää nimen alkupuolelle merkkejä ("Length" => "m_fLength"), jolloin oikea muuttuja pitää selata listasta. Aakkosellisesta jäsenhakemistosta se taas löytyy nopeammin loogisesta kohdasta "len" kuin "m_f".

En käsitä, mitä tekemistä muuttujan tyypin tietämisellä on tyyppimuunnosten kanssa. Harvemmin sillä saa paikattua tilannetta, jos tyyppi on väärä. Oikeastaan ainoa kiltisti muuttuva tapaus ovat luvut, ja niiden kanssa taas muuttujan merkityksestä (nimestä) voi yleensä päätellä, mitä tyyppiä se on. Value on luonnollisesti lähes aina huono nimi muuttujalle, koska siitä ei voi päätellä juuri mitään.

Lintu kirjoitti:

Englanniksi siksi, että muutkin varatut sanat edustavat englantia, eikä suomea.

Tämä on mieltymyskysymys.

Lintu kirjoitti:

Jos teet ison projektin ja sen ostaa koodeineen/docuineen ulkomaalainen yhtiö. Ei sinun tarvitse käydä uudelleen läpi kirjoittamaasi suomenkieltä.

Toki, jos tuollaisesta tilanteesta on kysymys. Kyllä meilläkin töissä koodataan englanniksi. Kukaan tuskin tulee kuitenkaan ostamaan esimerkiksi Ohjelmointiputkan koodivinkkejä Yhdysvaltoihin. ^^

Toivottavasti itsekin käsität, ettei koko nimeämiskysymyksessä ole mitään mieltä, kunhan nimeäminen kunkin moduulin sisällä on yhdenmukaista ja nimissä on jotain järkeä (vrt. pi, pa, ThisIsSomeTemporaryVariable <> pituus, paino, tmp).

Uuden nimeämiskäytännön omaksuminen on itse asiassa melko helppoa ja nopeaa. Mieluummin kannattaa opetella koodaamaan käyttäen useita erilaisia nimeämis- ja muotoilutapoja, kun jumittua johonkin tiettyyn konventioon, koska mitään ainoaa oikeaa tapaa ei todellakaan ole olemassa. Jos ei pysty sopeutumaan muutokseen, on aika hankala osallistua sellaisiin projekteihin, jotka noudattavat jotakin itselle vierasta koodaus- tai nimeämistyyliä. Sillä, että projektin sisällä käytetään yhtenäistä koodaus- ja nimeänmiskonventiota, on nimittäin paljon enemmän merkitystä kuin sillä, minkälainen tämä konventio on.