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 PascalCase
dla nazw klas, jak i ALL_CAPS
dla stałych globalnych, ale dla innych identyfikatorów dużo używa kodu Java, mixedCase
podczas 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ć?
c++
coding-style
coding-standards
David Z
źródło
źródło
Odpowiedzi:
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.
źródło
egptr
,sputn
iuflow
jakunderflow
. To jest po prostu zabawne!) W każdym razie, tak, lib std obecnie używa all_lowercase_with_underscores.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,
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,
Wreszcie, jeśli chodzi o podkreślenia kontra przeplatane wielkie litery,
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
źródło
const
z C ++, więc musiało się to zdarzyć bardzo dawno temu i na długo przed Javą, prawdopodobnie dla C89.+1
za „Bądź konsekwentny!” Czytając to, zastanawiam się, dlaczego zapomniałem wspomnieć o tej najważniejszej regule w mojej odpowiedzi, skoro nigdy nie zapomniałem powiedzieć o tym uczniom. Przypuszczam, że mi wybaczysz, jeśli dodam ją teraz do mojej odpowiedzi?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.
źródło
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ć
rw
wiersza, gdyrow
jest 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.
źródło
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.
źródło
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.
źródło
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
źródło
std::string
Vs.gnawme::string