Leading underscore használata C++ azonosítókban

 ( kisg | 2018. május 22., kedd - 21:31 )

Egy nagy múltú Budapesti Egyetem nagy múltú képzésén azt tanítják a hallgatóknak, hogy C++-ban az a konvenció, hogy az osztályok privát mezőinek nevét leading underscore-ral kell kezdeni.

class X {
private:
int _mezo1;
int _mezo2;
}

Szerintem ez egy nagyon rossz gyakorlat C-ben és C++-ban, mivel általában az underscore-ral kezdődő szimbólumok a standard library és a compiler "érdekkörébe" tartoznak.

A CPP Reference szerint valóban így van az esetek nagy többségében: http://en.cppreference.com/w/cpp/language/identifiers

Lehet arról vitatkozni, hogy konkrétan ez az eset nincs reservednek jelölve, de az egy mindenképpen rossz gyakorlat szerintem, ha reserved-nek kinéző szimbólumot használunk a kódunkban normál adattagként.

Mi a véleményetek?

Kérem, hogy ne offoljuk szét a topicot azzal, hogy a $másik nyelvben az underscore konvenció, én is tudom, hogy vannak ilyenek. Itt most a C és C++ -ról van szó.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szerintem nem para. Mi egyébként a standard-hez gyakorlatilag soha nem használjuk a using namespace-t, így össze sem akadhat. BTW: volt olyan hely, ahol kb. így nézett ki a kóding konvenció (member előtt underscore, argumentum után underscore, helyi változó előtt/után semmi):

class A
{
int _member;
public:
voif f(int arg_)
{
auto local = 0;
}
};

És a kód meglehetősen jól olvasható volt.
--
https://naszta.hu

Szerintem a compilert nem fogja megzavarni. Legfeljebb elé tesz még egy underscore-t. Gondolom, ők is kipróbálták legalább egy compilerrel. Ettől még lehet hülyeség vagy nem hülyeség, a kódolási konvenciók egy része ráadásul ízlés dolga. (Én nem raknám oda.)

Gaz, ha ugy tanitjak, hogy *ez* vagy *az* A konvencio, es nem ugy, hogy ahany haz, annyi szokas, ha van egy jol definialt konvencio, azt illik kovetni attol fuggetlenul, hogy neked tetszik-e vagy nem.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Azonos nyelveken belul (ez C-re es C++-ra is vonatkozik) is vannak kulonbozo "konvenciok". Pl. egyiptomi vagy normalis {}, behuzas tabbal vagy space-ekkel (utobbi eseten mennyivel), stb. Elozo munkahelyemen egy kodon belul is volt tobb kulonbozo szokas, es az volt a mondas, hogy kovesd a "blend-in" elvet. Szoval ha az adott file kovet valamit, es beleirsz 10 sort, akkor csinald olyanra, amilyen a kornyezete. Ha uj file-rol van szo, akkor az adott modul/konyvtar/akarmi felepitesehez alkalmazkodj. Szerintem ez normalis elv, ha az elejen nem kotottel ki szigoru szabalyokat. (ha kikotottel, az is jo, akkor teljesen egyseges lesz)
Az elnevezeseknel is hasonlo a helyzet szerintem. Ha valami winapi-t hasznalo kodot irsz, lehet, hogy Hungarian Notationt hasznalsz, ha kernelmodult, akkor az ott megszokottat, ha valami speci grafikus konyvtarat, akkor az ottanit. Akar egy nagyobb projecten belul is lehet tobbfele (kernel modul, plusz valami GUI-s alkalmazas, amivel kommunikal).

Ugy emlekszem, alahuzassal a fordito makroi kezdodnek (de azok csupa nagybetusek), szoval kisbetukkel akar hasznalhatnad is a privat dolgaidhoz, bar en nem emlekszem, hogy valaha lattam volna ilyen projectet. Olyat viszont mar talaltam, hogy egy uj architekturara portolt kod nem fordult, mert valamelyik szimbolum osszeakadt egy kulso libbel. (SH7 meg wince volt alatta, es visual studioval fordult)

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Szerintem jó, ha a membereket (és esetleg az argumentumokat) első ránézésre meg lehet különböztetni a lokális változóktól. Sokan használunk erre valami konvenciót.
Az viszont szerintem teljesen értelmetlen, ha csak a privát memberek különböznek.

Tenyleg pontatlan, mert a nyelvben szerintem semmilyen eloiras nincsen arra nezve, hogy hogyan nevezed el a privat adattagokat.

Az valoban igaz, hogy vannak olyan kodolasi konvenciok, ahol ez a szokas, de ez messze nem univerzalisan elterjedt.

Szerintem amugy meg teljesen felesleges az aggodalom, mert nyilvan ebben az esetben a szimbolumok nem utkoznek sem forditasnal, sem linkelesnel. Amugy meg van egy halom tenyleg nagyon altalanos nev pl. libc-ben, posix api-ban, c++ stdlibben, amit ha kerulni akarsz, akkor vakarhatod a fejedet. (pl. select(), poll(), remove(), count(), find()). Dehat erre vannak az intuitiv scoping szabalyok, hogy egy adott helyen melyik nev fog kivalasztasra kerulni. Plusz ha valami vegkepp nagyon utkozik, akkor meg mindig lehet nevterezni is.

Amugy meg szerintem a mindenfele fordito altal hasznalt makrok es fuggvenyek nevei nagyon gyakran dupla alahuzassal kezdodnek, szoval az utkozes tobbnyire kizart.

biztos hogy nincs semmilyen előírás és lehet "névterezni"?

https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

nekem még sosem okozottt problémát hogy __abcd neveket használok (szoktam), de ha sok pénzről lenne szó akkor betartanám a szabályokat.

Szerintem egy programozás órán nem arra kellene koncentrálni, hogy hogyan dekoráld a kódodat, mert erre n+1 féle szokás/konvenció van (lásd fentebb), hanem a gondolkodásmód átadására...

Jaja, pl. windows-hoz kotodo c++ projektekben gyakran a hungarian notation/camel casing/pascal casing megy, underscore ritkabb. Unix-hoz jobban kotodo projekteknel en gyakrabban lattam az stdlibc++ konvencioit. De tenyleg mindenre van ellenpelda is.

Osszessegeben veve talan annyit kellene elmondani a tanuloknak, hogy mi az a coding standard, eshogy egy programozoi kozossegbe bekerulve erdemes errol tajekozodni es kovetni, ha jofejek akarunk lenni (vagy egyaltalan szeretnenk, hogy a kodunkal erdemben foglalkozzanak).

Pont a gondolkodásmódról van szó: elvileg ugye szabadon kialakíthatsz coding style-t, viszont a saját dolgunkat nem kéne megnehezíteni és potenciális hibalehetőségeket bevinni olyan dologgal, amit önkényesen határozunk meg. Pl. sok helyen (Google, ROS style guide) használnak trailing underscore-t, amivel semmi gond nincsen. Nem tetszik esztétikailag, de elfogadom, használható.

Más, hasonló téma:
Hibának tartom, hogy a Linux kernelben az egysoros if -nél nem nyitnak új blokkot. Elfogadom, hogy a kenel fejlesztők így döntöttek, és ha kernel modult írok, amit be akarok nekik küldeni, akkor követem.

De kezdő programozóknak akkor is azt az ökölszabályt mondom, hogy mindig nyiss blokkot az if, for, while ... stb. után, mert jobb ha ezt tanulja meg először, és ha majd profi lesz, akkor esetleg el lehet vitatkozni egy sör mellett a kivételekről. De addig spórolunk sok-sok felesleges költséget azzal, hogy egy teljes hibaosztályt kiküszöbölünk egy egyszerű, könnyen megjegyezhető szabállyal.

Szerintem ezt a gondolkodásmódot kellene átadni.

Az első részhez: a gondolkodásmódnak része, hogyha elmagyarázzák, hogy igen vannak coding style-ok meg konvenciók és ha bekerülsz egy helyre akkor ezekről érdemes tájékozódni.

Az if-es dologgal egyetértek, kezdők egy csomó szívástól tudják magukat megkímélni. Láttam azonban erre is ellenpéldát: volt egy olyan kurzus ahol annyira beleverték a hallgatókba, hogy a switch-case-nél minden case-hez már előre rakják ki a break;-et, hogy utána olyan helyen sem jutott eszükbe kihasználni a "fall through"-t ahol értelme lett volna.
Érdekes dolog egyébként programozást tanítani, pont ezek miatt a dolgok miatt: hogyan adj át mindig csak annyi tudást amennyi még felfogható úgy, hogy közben ne alakíts ki rossz beidegződéseket. Pedig az ember azt hinné, hogy ilyen egzakt dolgot, mint a programozás tök könnyű jól oktatni :D

Ok, tehát az mindenki szerint rendben van, ha azt tanítják az egyetemen, hogy _kisbetűvelKezdveOk, viszont a szabvány szerint _NagybetűvelKezdveReserved és __duplaUnderscoreIsReserved.

Tehát nem arról van szó, hogy ne lehetne kvázi szabadon meghatározni a coding style-t, hanem sikerül az 1000 opcióból egy olyat kiválasztani és oktatni, ami nagyon közel van a nem szabványoshoz, és akár csak véletlenül is bele tudnak a hallgatók futni egy ilyen problémába.

Ha már választani kéne, akkor vannak elterjedt, jó minőségű coding styleok, amiket lehet tanítani, pl.:
https://google.github.io/styleguide/cppguide.html

És elkezdtek egy kvázi-hivatalos ajánlás gyűjteményt is csinálni: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html

Ennek szerintem az az értelme, hogy ne keverd a paramétert a változóval. Pl:

class A
{
  private:
    int _size;
  public:
    A(int size) {_size = size};
}

--
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Lehet ilyen jelzést csinálni, lásd pl. a Google C++ Style Guide, de az az azonosító _végén_ van, mert az elején a fentebb leírtak miatt nem szerencsés.