[itk] Számítástechnika kezdőknek

C++ programozás kezdőknek - változók elnevezése

[2021. június 17.] [ christo161 ]

Az előző tananyagrészben arról már volt szó, hogy milyen szabályokat kell betartani egy változó elnevezése esetén (amik egyébként más dolgok, pl tömbök, függvények, osztályok, objektumok elnevezése esetén is érvényesek). Ebben a tananyagrészben nem az elnevezési szabályokról lesz szó, hanem arról, hogy (egyesek szerint) hogyan érdemes és hogyan nem érdemes elnevezni a változókat (például milyen szavakat használjunk, azokat hogyan válasszuk el egymástól, satöbbi).

Ebben a témában egyesek vérremenő vitákat folytatnak, én itt csak néhány alapvető tudnivalót ismertetek azok számára, akiknek teljesen ismeretlen a téma, nem állítom, hogy ennek a tananyagnak az elnevezései a legtökéletesebbek :)

Általában az egyes szervezetek/cégek meghatározzák, hogy a fennhatóságuk alatt álló projektek forráskódjában hogyan kell eljárni a változók elnevezése és egyéb design patternek tekintetében.

Szavak elválasztása

Átláthatóbbá teszi a kódot, ha a nevekben (azonosítókban) nem csak egybeírjuk a több szóból álló nevekben a szavakat, hanem valahogy szemmel láthatóan elválasztjuk őket egymástól. Ennek a két legismertebb módja a snake_case és a camelCase.

snake_case

A C++ nyelvben talán a legnépszerűbb elnevezési stílus a snake_case, amely szerint az egyes szavak közé egy alsóvonalat írunk a nevekben (azonosítókban). Példák változók definiálása (létrehozása) esetén:

int variable_example_1{};
double variable_example_2{};
std::string variable_example_3;

camelCase

Alighanem a világ legnépszerűbb elnevezési stílusa a camelCase, mellyel C++ nyelvben is jó eséllyel találkozhatunk, de a Java és C# nyelvekben szinte biztos, hogy a legtöbb programozó ezt használja, amely szerint a szavakat egybe írjuk, az első szó kis betűvel kezdődik, a további szavak pedig nagy betűvel kezdődnek.
Példák változók definiálása esetén:

int variableExample1{};
double variableExample2{};
std::string variableExample3;

UpperCamelCase

Esetleg PascalCase-nek is szokták nevezni. Például Javaban, C#-ban, és nyilván Pascalban találkozhatunk vele. Javaban például a camelCase-el együtt használják (az osztályok neveit szokták UpperCamelCase szerint írni, a változók és függvények neveit pedig lowerCamelCase szerint), akár ugyanígy találkozhatunk vele a C++ nyelvben is.

Példa osztályok esetén:

class ClassExample {

int memberExample1;
std::string memberExample2;

//other private members and member functions

public:

//constructor(s)

int getMember1() { return memberExample1; }

std::string getMember2() { return memberExample2; }

//other public members and member functions

};

Jól látható, hogy csak az osztály neve van UpperCamelCase szerint írva, az osztály adattagjai és tagfüggvényei pedig lowerCamelCase szerint.

MACRO_CASE

Más néven ALL_CAPS vagy SCREAMING_SNAKE_CASE vagy esetleg más nyelvek esetén CONST_CASE, de a C++ nyelvben csak a preprocesszor makrók elnevezésénél ajánlott a használata, konstansok (const típusminősítővel ellátott változók), esetleg enumok esetén ellenjavallt.

Egyéb

Léteznek még egyéb, a fentiekhez hasonló elnevezési konvenciók, amikkel kevesebb eséllyel találkozunk a C++ nyelvben. Ezek jellemzően vagy a fentiek kombinációi (pl. alsóvonalat tartalmaznak és nagybetűvel is kezdődnek az egyes szavak), esetleg alsóvonal helyett kötőjel van bennük.

Melyiket válasszuk?

A C++ standard library a snake_case-t alkalmazza és a Core Guidelines is ennek a használatát javasolja. Persze nem kötelező ezt használni minden C++ projektben, és könnyen találkozhatunk olyan C++ projektekkel, forrásfájlokkal, ahol nem ezt vagy nem csak ezt használják.
Elképzelhető, hogy egy projektben például a fentiek közül többet is használnak, viszont jó esetben mindig más dolgok (pl. változókhoz lowerCamelCase, osztályokhoz UpperCamelCase) elnevezéséhez.
Esetleg az is előfordulhat, hogy egy projekten belül több libraryt is használunk (nem csak a C++ standard libraryt), és a különböző libraryk eltérő design patterneket használnak. Ezen természetesen nem tudunk (de ha esetleg tudunk, akkor sem érdemes) változtatni.

Milyen információk szerepeljenek vagy ne szerepeljenek a nevekben?

Egy változó neve utaljon a benne tárolt tartalomra

Az egyik legáltalánosabb tanács, hogy egy egy változót annak megfelelően nevezzünk el, hogy milyen jellegű adatot fogunk benne tárolni. Például ha egy stringben valamilyen idézetet tárolunk, akkor nevezzük el quote-nak, vagy idezetnek, vagy ha például egy int típusú változóban valaminek a darabszámát tároljuk, akkor nevezzük number_of_elements-nek vagy elemszamnak vagy valami hasonlónak.

Eszerint tehát nem javasolt a semmitmondó változónevek használata, például: a, b, x, y, n, number1, number2, string1, string2, data, satöbbi.

Ebben a tananyagban ezt nem mindig tartjuk be, mert az alapvető ismeretek bemutatásához nem kell az egyes példákat különösebb értelemmel felruházni.

7 Names We Should Never See In Code
https://www.youtube.com/watch?v=CgHn2WPyzhk

A változó szerepének jelentőségét tükrözze a nevének a hossza

//

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#nl7-make-the-length-of-a-name-roughly-proportional-to-the-length-of-its-scope

Típus a nevekben (Hungarian notation)

//

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#nl5-avoid-encoding-type-information-in-names

Mértékegység a nevekben

//

Egyéb tanácsok

//

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es8-avoid-similar-looking-names

https://www.learncpp.com/cpp-tutorial/keywords-and-naming-identifiers/

https://www.fluentcpp.com/2017/01/30/how-to-choose-good-names/

Összefoglalók

https://hu.wikipedia.org/wiki/Elnevez%C3%A9si_konvenci%C3%B3k_(programoz%C3%A1s)

A bejegyzés trackback címe:

https://itkezdoknek.blog.hu/api/trackback/id/tr4816560360

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása