Autor Wątek: [C++] Nazewnictwo zmiennych  (Przeczytany 1304 razy)

Offline slowbro

  • Użytkownik

# Czerwiec 14, 2017, 23:41:16
Cześć

Na rozruszanie forum:) Są ogólnie jakieś wytyczne stosowania nazewnictwa zmiennych wykorzystywanych w programowaniu w C++ np. notacja węgierska. Czy z Waszego doświadczenia wynika, że warto stosować jakieś konkretne dobre standardy nazewnictwa zmiennych? Jeżeli tak to jakie? Czego warto unikać i co się całkowicie nie sprawdza?

Jakiś czas temu stosowałem notację węgierską, ale po jakimś czasie jak wraca się do kodu trudno się w nim połapać...

Pozdro

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Czerwiec 14, 2017, 23:45:14
Ja się ograniczam się do nazywania zmiennych/pól z małej a metod z dużej litery. Metody dosaję alfabetycznie bo mi się wtedy łatwiej szuka i to tyle.

Offline lethern

  • Użytkownik

# Czerwiec 14, 2017, 23:53:01
z rzeczy które warto, podejrzewam że warto nie stosować wtytycznych, które miały rozwiązać pewne problemy - które już nie istnieją (notacja węgierska)
poza tym samo nadawanie nazw jest sztuką i jednocześnie źródłem błędów (przy nieprawidłowym nadawaniu nazw rzeczom) - tak mówią mądre książki :D
+1 laggyluk (ale nie ograniczałbym się do tego ;p)

hmm jednak wrzucę pare swoich notek (które działają dla mnie)
-różne sposoby pisania wykorzystuję do różnych rzeczy, czyli pisowniaCamelCase przy normalnych rzeczach, ale z dodatkiem podkreśleń kiedy coś rozdzielam - np. wolę mieć "threadSafe_getDocumentId" - czytelność jest na pierwszym miejscu i akurat takie rozdzielenie mi pomaga (nie musi innym), stąd mieszany styl - w paru projektach mam to szczęście, że mogę sobie na to mieszanie pozwolić, kiedy mój kod jest w ograniczonym stopniu / nie jest czytany przez innych
-idąc dalej, CAPS_LOCK dla stałych lub podobnych dziwactw (np. C-macro) - żeby bez zastanawiania się było widać, że nimi (dziwactwami) są. Idąc tym tokiem rozumowania, stosuję podobny sposób do nazywania klas (czyli nie camelCase, tylko wielką literą - MojaKlasa). Choć staje się to do pewnego stopnia zbyteczne jeśli masz odpowiednie kolorowanie składni!
-długość nazwy - fajnie by było, aby była taka, jaką uznaliśmy za najlepszą do łatwego czytania i by ktoś nadal wiedział o co chodzi (włączając w to nas samych po paru miesiącach przerwy). Nazywanie metody "run" w klasie "handler" to zbrodnia, choćby zwykłe "MailSender" i "send" - krótkie i lepsze, ale czasem warto mieć dłuższą nazwę (przynajmniej niektóre struktury pojawiają się rzadziej - np. nazwy klas - więc czemu nie) - po co ktoś ma przeklikiwać projekt, żeby znaleźć o co chodzi? Z drugiej strony, Jeśli mamy zmienną, którą używamy w kolejnych 50 linijkach nonstop, to oczywiście lepiej ją nazwać maksymalnie skrótowo - skoro jest wszędzie, to nie trzeba jej dosadnie tłumaczyć, przeciwnie, zwiększyć czytelność
-(jak napisałem na samym początku, warto w ogóle wiedzieć jakie są problemy, które rozwiązują rzeczy których używamy - zalecenia/styl/zasady itd.) plus pewnie trzeba troche samemu doświadczyć - tych problemów z długością kodu czy czytelnością - po paru latach wrócić znowu do dyskusji, zobaczyć te pomysły w nowym świetle
« Ostatnia zmiana: Czerwiec 15, 2017, 01:07:33 wysłana przez lethern »

Offline Mergul

  • Użytkownik

# Czerwiec 15, 2017, 00:39:10
Napewno nie tworzyc bardzo dlugich nazw zmiennych jak np. glDrawElementsInstancedBaseVertexBaseInstance.
Nie nazywac zmiennych po polsku.
Napewno warto rozróżniać metody, zmienne globalne, pola itd. Ja ostatnio jako, źe kodze w D to po części przystosowalem się do nazewnictwa camelCase se zaczynamy z małej litery i kazdy kolejny czlon z duźej, funkcje i metody w ten sposob, pola klasy lisse malymi rozdzielajac podkreslnikiem.
Ostatnio trafilem na cos co mi sie spodobalo, zeby prywatne zmienne klasy zaczynac m_.. nie wiem czemu, ale brat zasugerowal ze chodzi o m jak member :D

Offline Hypersomnia

  • Użytkownik
    • Hypersomnia dev diary

  • +2
# Czerwiec 15, 2017, 00:42:40
Dodam od siebie, że o wiele ważniejsze od wyboru stylu jest konsystencja użycia. Najgorsze co można zrobić to pomieszać dwie różne konwencje w jednym projekcie.

edit: co nie znaczy że coś rodzaju threadSafe_getDocumentId jest koniecznie złe, chodzi tylko o to aby wszędzie posługiwać się tymi samymi zasadami, jakiekolwiek by nie były.

Mi osobiście podoba się underscore_case bo wydaje się jakaś taka nostalgiczna, a przy okazji wszystkie symbole z przestrzeni std:: są w tej konwencji więc mi się to fajnie zgrywa.
« Ostatnia zmiana: Czerwiec 15, 2017, 02:13:49 wysłana przez Hypersomnia »

Offline Patrulek

  • Użytkownik

# Czerwiec 15, 2017, 16:19:30
Kiedyś używałem camelCase'a do zmiennych i nazw funkcji, ale później wypracowałem sobie styl, żeby zmienne pisać underscorem. Najważniejsze to  trzymać się jednej konwencji w projekcie. Póki piszesz coś samemu, to po prostu przez doświadczenie wypracujesz sobie własny styl, w którym będzie Ci się później dobrze czytać kod, w grupowym projekcie i tak będziesz musiał prawdopodobnie z niego zrezygnować na rzecz całego teamu. Nazewnictwo jakie ja stosuję:

Zmienne:
- lokalne / pola klasy - underscore (np. is_alive), jeżeli dodatkowo piszę w edytorze/IDE bez wsparcia odnośnie typów lub w językach z typowaniem dynamicznym dodaję przed nazwą zmiennej jej typ podstawowy (np. b_is_alive)
- parametry funkcji - underscore z poprzedzonym podkreślnikiem (np. _is_alive); ten trick wykorzystuję dlatego, że nie podobało mi się pisanie w Javie słówka 'this' żeby przypisać zmienną o tej samej nazwie i tak mi już zostało

Stałe / makra:
- underscore, gdzie cała nazwa pisana jest wielkimi literami (np. DAY_TO_SECONDS)

Funkcje:
- camelcase, od razu widać co jest zmienną a co metodą (np. doSomething())  (w pracy z kolei używamy też underscore'a żeby nazewnictwo było jednakowe ze standardowymi pakietami - to akurat w PLSQL - jednak żeby odróżnić nieco od nazw zmiennych zaczynamy każdy wyraz wielką literą, np. Do_Something())
- niektóre języki pozwalają na zapisanie wywołania metody bezparametrowej w taki sposób, że wygląda jak zmienna (bez użycia () za nazwą), mimo wszystko polecam stosować nawiasy (to tak poza C++)

Typy:
- PascalCase (np. SomeClass)

Najważniejsze to stosować nazwy, które jednoznacznie określają co dana zmienna/metoda/klasa oznacza. Czasem jest trudno, podasz jakąś nazwę, żeby za 5 min ją zmienić i to jest ok, o ile poprawi to czytelność kodu.

Co do długich nazw nie są one problemem dopóki:
- korzystasz z edytora, który ma podpowiadanie kodu
- jest bardzo mało takich nazw w module
- zmienne te nie posiadają wspólnego członu (odpowiednio długiego) na początku nazwy

A propo poszukiwania własnego stylu, możesz albo wypracowywać go samemu, albo popatrzeć w jakieś otwarte projekty i z nich czerpać inspiracje, jeśli uznasz że jakiś projekt dobrze Ci się czyta, to być może warto przetestować te praktyki nazewnictwa u siebie.

Offline DezerteR

  • Użytkownik

# Czerwiec 15, 2017, 17:24:32
camelCase jest raczej standardem, inaczej możesz zrobić sobie duże kuku jak pójdziesz do pracy. Mieszanie underscorów i camelCase zrobi ci syf z kodu, od tego masz edytor żeby kolorował zmienne/metody inaczej, znacznie szybciej czyta się kod napisany spójnym stylem.

Co do przedrostków stosuje się p_ i l_ dla parametrów i zmiennych lokalnych, ale to mnie irytuje akurat, m_ do pól prywatnych ma jeszcze trochę sensu.
 
Żadnych underscorów na początku bo może się to mylić z funkcjami systemowymi/jakimiś specjalnymi.

Długie nazwy jeśli mają sens.

Offline Mergul

  • Użytkownik

# Czerwiec 15, 2017, 17:39:04
Moje nazewnictwo praktycznie pokrywa się z tym podanym przez @Patrulek :D

Mieszanie underscorów i camelCase zrobi ci syf z kodu, od tego masz edytor żeby kolorował zmienne/metody inaczej, znacznie szybciej czyta się kod napisany spójnym stylem.
Tutaj się nie zgodzę. IDE nie koloruje zmiennych, funkcji itp. chyba żadno tego nie robi, koloruje zazwyczaj typy i słowa kluczowe. Zmienne zaczynające się od podkreśliników najzwyczajniej mi się nie podobają, ale stosowanie wszędzie tylko camelCase wcale nie poprawia czytelnosci kodu, wszystko wygląda identycznie. Chyba im więcej rodzajów tym czytelniej jeżeli nauczysz się je rozpoznawać, człowiek wgl. ma tendencje do tego że woli różnorodność niż tekst, szybciej wpadają do głowy kolory, obrazki i wgl. niż sam tekst. Więc stosowanie różnych rodzajów notacji dla różnych elementów poprawia czytelność kodu.
Chociaż jeżeli chodzi o wgryzienie sie w czyjś kod to nic nie ułatwia tego tak jak nazwy zmiennych i ukłąd kodu, rozgraniczanie "myśli" enterami czy nawet komentarzami, nazywanie zmiennych w sensowny sposób itp.

Offline Hypersomnia

  • Użytkownik
    • Hypersomnia dev diary

# Czerwiec 15, 2017, 17:58:11
IDE nie koloruje zmiennych, funkcji itp. chyba żadno tego nie robi, koloruje zazwyczaj typy i słowa kluczowe.

Nie wiem jak tam z innymi językami i z innymi systemami niż Windows, ale Visual Studio 2017 może kolorować chyba wszystkie istotne konstrukty C++:



włączając w to parametry funkcji, funkcje, membery, nawet może rozróżniać klasy od szablonów i rozróżniać zmienne lokalne od globalnych.

szybciej wpadają do głowy kolory, obrazki i wgl. niż sam tekst.

Zdecydowanie. Jak popatrzę na swój kod bez kolorów do których jestem przyzwyczajony to dosłownie muszę się go nauczyć jeszcze raz... ale może to nie jest dobry znak.

Offline DezerteR

  • Użytkownik

# Czerwiec 15, 2017, 18:20:47
VS Code/Atom też dają radę. Ostanio siedzę w fault investigation i czytam mnóstwo cudzego kodu więc powiem tyle że im spójniej i mniej udziwnień tym lepiej.

Offline Kyroaku

  • Użytkownik

# Czerwiec 15, 2017, 19:30:46
Notacja węgierska według mnie to okropieństwo. Chociaż swego czasu uważałem ją za bardzo praktyczną (bardzo krótki okres mojego życia :D).

Ja przez cały czas próbowałem różnych styli pisania i od niedawna wydaje mi się, że się ustaliłem:
enum EColor {
eColorRed,
eColorGreen
};
Dodaję "Color" przy każdym polu ze względu na to, że to są jednak nazwy globalne (tak, wiem, że istnieje enum class) i staram się zachować ich unikalność. Troche dłuższa nazwa mi w tym wypadku nie przeszkadza.
class MyClass
{
MyClass(float firstParameter, int secondParameter);
float mMyFloat;
int mMyInt;
float GetFloat();
void SetFloat(float floatParameter);
};
Do pól klasy dodaje przedrostek "m" (też to tłumacze, jako "member" :D). To pozwala mi mieć zarówno pola, jak i metody pisane z dużej litery, nie licząc tego przedrostka. Nie podoba mi się pisowniaCamelCase w takich miejscach i używam jej do parametrów, zmiennych tymczasowych, etc.

Makra, stałe i podobne standardowo piszę duzymi literami, lub KazdyCzlonZDuzejLitery, w przypadku niektorych makr, jak np:
#define CastToMyClass(a) ((MyClass)a)

Offline lethern

  • Użytkownik

# Czerwiec 15, 2017, 19:40:47
Cytuj
Tutaj się nie zgodzę. IDE nie koloruje zmiennych, funkcji itp
Witamy w XXI wieku, gdzie nadal programuje się w notatniku! Visual Studio ftw
U mnie kolorki są http://i.imgur.com/19frN0w.png (no nie aż tak szczegółowe)

Cytuj
enum EColor {
        eColorRed,
        eColorGreen
};
To ma sens w C++, i nie ma w C# (gdzie i tak musisz pisać EColor.eColorRed, jeśli nie zrobisz static importów)

« Ostatnia zmiana: Czerwiec 15, 2017, 20:06:39 wysłana przez lethern »

Offline matheavyk

  • Użytkownik

# Czerwiec 15, 2017, 20:05:11
Ja najbardziej lubię pisać w takim stylu, jakim większość ludzi używająca danego języka się posługuje.
Używam innego stylu w C#, javascript, Java, czy PHP.

Najprostsza sprawa jest z C# - wystarczy pisać mniej więcej tak, jak jest na MSDNie, bo większość ludzi tak pisze. A jako, że używam Unity3D, to też stamtąd biorę wzorce (dokumentacja, społeczność).

Offline Mergul

  • Użytkownik

# Czerwiec 15, 2017, 21:07:50
Witamy w XXI wieku, gdzie nadal programuje się w notatniku! Visual Studio ftw
U mnie kolorki są http://i.imgur.com/19frN0w.png (no nie aż tak szczegółowe)
W tym co pokazałeś pokolorowane są tylko typy, nazwy zmiennych nie są pokolorowane. Co znaczy że kiedy zobaczysz je w kodzie, a nie w klasie to nie masz pojecia czym sa po ich wyglądzie :D O to mi chodziło, że nie koloruje Ci takich rzeczy jak u Ciebie: conn, command, HD_TABLE, errorState. No i w podanym przykładzie nie masz camelCase. Masz underscore dla parametrów funkcji i dużymi underscore dla stałych :D

Offline lethern

  • Użytkownik

# Czerwiec 15, 2017, 21:57:26
u mnie zmienne różnego pochodzenia nie są rozróżniane bo ja tego nie potrzebuję, ale VS pozwala to zrobić- o czym pisał poprzednik..
« Ostatnia zmiana: Czerwiec 15, 2017, 22:00:07 wysłana przez lethern »