Czy istnieje wspólna konwencja wielkich liter w C ++? [Zamknięte]

Dużo pracuję w Pythonie i Javie, a oba te języki mają dość powszechne (choć nie uniwersalne) konwencje dotyczące używania wielkich liter w identyfikatorach: zarówno PascalCasedla nazw klas, jak i ALL_CAPSdla stałych globalnych, ale dla innych identyfikatorów dużo używa kodu Java, mixedCasepodczas gdy dużo używa kodu Python underscore_delimiters. Wiem, że żaden język ani biblioteka nie wymusza żadnych wielkich liter, ale odkryłem, że kiedy trzymam się standardowych konwencji dla języka, którego używam, mój kod wydaje się znacznie bardziej czytelny.

Teraz zaczynam projekt w C ++ i chciałbym zastosować ten sam pomysł. Czy jest jakaś najczęstsza konwencja wielkich liter, o której powinienem wiedzieć?

Czy jest jakaś najczęstsza konwencja wielkich liter, o której powinienem wiedzieć?

C ++ jest oparty na C, który jest wystarczająco stary, aby opracować całą masę konwencji nazewnictwa do czasu wynalezienia C ++. Następnie C ++ dodał kilka, a C nie był bezczynny, myśląc o nowych. Dodaj do tego wiele języków pochodnych C, które rozwinęły konwencje nazewnictwa C wynalazcy do tego stopnia, że ​​zapłodnili ponownie C i C ++ ... Innymi słowy: C ++ nie ma jednej, ale wiele takich konwencji.

Jednak jeśli szukasz jednej konwencji nazewnictwa, równie dobrze możesz przyjrzeć się standardowej konwencji nazewnictwa biblioteki , ponieważ jest to jedyna, którą wszyscy programiści C ++ będą musieli znać i być do niej przyzwyczajeni.

Jednak najważniejszą zasadą jest: Bądź konsekwentny!

Co ciekawe, kiedy zaczynałem od mieszania PascalCase i camelCase i brałem udział w licznych projektach z jeszcze liczniejszymi konwencjami nazewnictwa, z biegiem lat coraz bardziej utknąłem w konwencji standard_library_convention. Nie pytaj mnie dlaczego.

Najpierw ustalmy, że ALL UPPERCASE jest odleżyną i należy ją zminimalizować.

Dlatego w C i C ++ jest on używany jako konwencja dla makr i tylko makr, ponieważ makra są równie brzydkie, by nie powiedzieć zło.

Wczesne C nie miało stałych, więc stałe musiały być wyrażone jako makra. Ponadto, w tych wczesnych dniach programy były znacznie krótsze, więc można było zastosować praktyki, które są dziś niezbyt dobre (np. IIRC Brian Kernighan napisał kod z dużą ilością makr innych niż wielkie litery). Ponadto w tamtych czasach istniały klawiatury, które nie miały małych liter; Użyłem jednego takiego, na norweskim komputerze Tandberg EC-10, około 1980 lub 1979, tak myślę.

Tak więc Java od początku przyjęła konwencję wielkich liter dla stałych C. Tymczasem, a może nawet wcześniej (nie jestem pewien chronologii tutaj), C ma stałe. Jednakże, chociaż oczywiście niektórzy / wielu programistów C utknęło we wcześniejszej konwencji z konieczności stałych jako makr pisanych wielkimi literami, programiści C ++ byli bardziej rozsądni.

Dużym problemem w dzisiejszych czasach jest to, że najpierw ludzie uczą się Java, a najpierw C (z konwencjami ze średniowiecza), a potem przychodzą do C ++, zabierając ze sobą tę okropną konwencję wielkich liter.

Więc,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Może pomyślałeś, że w żartach wspomniałem o klawiaturach pisanych tylko wielkimi literami. O nie. Ponieważ jest to tylko najstarsze, najbardziej archaiczne ograniczenie technologii, które doprowadziło do konwencji nazewnictwa lub przynajmniej wpłynęło na to, jak źle się wydawały. Następnie pojawił się problem z 7-bitową transmisją szeregową, która spowodowała odpowiednie problemy z używanymi kodami znaków (kodowanie znaków w gazecie), co oznaczało, że musiałeś ograniczyć się do liter alfabetu angielskiego, od A do Z.

Właściwie polecam nadal to robić. Tam jesteśmy! Nie dotarliśmy dalej.

W chwili obecnej, począwszy od 2011 r., Standardowe C ++ obsługuje ogólne Unicode w nazwach (i robi to od 1998 r.), Podczas gdy rzeczywiste implementacje C ++ nie. W szczególności kompilator g ++ ma charakter narodowy. Wynika to z ograniczeń technologicznych średniowiecza.

Więc,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Wreszcie, jeśli chodzi o podkreślenia kontra przeplatane wielkie litery,

• Zarezerwuj łatwo rozpoznawalny formularz dla nazw typów.
• Zarezerwuj ALL UPPERCASE dla makr.
• Bądź konsekwentny.

Myślę, że tak naprawdę, z wyjątkiem reguł takich jak „ogólnie unikaj nazwy jednoliterowej, z wyjątkiem (pętli, szablonu param, bla bla)” i „unikaj używania l, łatwo mylonego z 1” i „unikaj wielkich liter O, łatwo mylących z 0 ”. Ponadto, oczywiście, unikaj używania nazw zastrzeżonych, takich jak rozpoczynanie od znaku podkreślenia, a następnie wielkich liter, zawierających dwa kolejne znaki podkreślenia lub rozpoczynanie od znaku podkreślenia i znajdowanie się w globalnej przestrzeni nazw.

Pozdrawiam i hth

Zwykle trzymam się konwencji, którą widzę najbardziej w istniejących bazach kodu dla tego języka. W przypadku C ++ zwykle widzę camelCase. W przypadku Ruby lub PHP zwykle widzę takie rzeczy.

Realistycznie rzecz biorąc, najważniejsze jest to, aby wybrać konwencję stylu, która nie jest całkowicie szalona (dOnT_dO_tHiS) i być z nią zgodną. Spraw, aby styl nie zmieniał się w całym kodzie dla konkretnego projektu. Jeśli pracujesz nad istniejącym projektem, powinieneś wybrać styl, który już tam jest.

No cóż, jest System Węgierski, który jest naprawdę powszechny nawet teraz, ale wolę podciąć sobie gardło niż polecić. Aplikacje węgierskie są lepsze, ponieważ ich znaki opisowe naprawdę wskazują na semantykę, choć wydaje mi się, że jest to zbyt chętnie używane skróty, gdy wystarczy krótkie słowo. (Aby skorzystać z przykładu z tej strony Wikipedii, po co używać rwwiersza, gdy rowjest tylko jeden znak dłuższy? To nie tak, że występuje globalny niedobór samogłosek).

Jednak realistycznie najważniejsze jest przestrzeganie konwencji ludzi, z którymi pracujesz . Naprawdę. Większość konwencji działa wystarczająco dobrze, zwłaszcza jeśli jest konsekwentnie stosowana. Niespójność jest najgorsza (nawet bardziej niż węgierskie systemy, których nienawidzę). A jeśli jesteś sam, użyj tego, co chcesz.

Z tego, co widziałem, różni się w zależności od projektu.

Osadzone podkreślenia są prawdopodobnie bardziej tradycyjne / częściej używane w C na Uniksie. Biblioteka standardowa również to przestrzega, więc prawie na pewno powinna być traktowana jako domyślna, do użycia, chyba że istnieje wystarczający kod używający innej konwencji, aby absolutnie wymusić użycie tej innej konwencji.

Windows (na przykład) używa futerału wielbłąda do większości swoich funkcji, więc sporo osób, które pracują dla systemu Windows, robi to samo. Jest to również dość powszechne wśród ludzi, którzy są naprawdę bardziej przyzwyczajeni do innych języków i starają się traktować C ++ tak, jakby to był dziwny wariant czegoś innego.

Użyłem zarówno standardowej biblioteki, jak i boost jako odniesień do konwencji nazewnictwa. Istnieje jednak problem z tym rozwiązaniem.

Biblioteka standardowa korzysta z konwencji nazewnictwa zaprojektowanej w celu ograniczenia kolizji z kodem. Częścią rozwiązania jest użycie wszystkich małych liter. Stąd użycie podkreślników zamiast camelCase.

Uważam, że camelCase jest czytelny. PascalCase jest często używany do nazw klas, ponieważ reprezentuje odpowiednik właściwego rzeczownika. Jednak złamię tę zasadę dla funktorów, które są bardziej reprezentatywne dla czasownika.

Staram się nie używać makr. Jednak kiedy to robię, makra wyglądają jak funkcje, kiedy mogą. Używam również wartości stałych lub wyliczeń zamiast stałych manifestu, dodatkowo unikając wielkich liter. Zazwyczaj poprzedzam te symbole literą „k”, aby wskazać, że są one stałe.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

Odnośnik opisuje konwencję nazewnictwa, która jest bardzo podobna do tych, które z powodzeniem stosowałem w co najmniej trzech firmach, w których pracowałem w przeszłości.

W przeciwieństwie do wcześniejszej odpowiedzi, unikałbym przestrzegania konwencji nazewnictwa Biblioteki Standardowej C ++ we własnym kodzie, choćby z innego powodu niż unikanie kolizji nazw z Biblioteką Standardową.

Ta poprzednia odpowiedź SO na pokrewny temat może również być interesująca: /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier