Różne tokeny w twoim kodzie (zmienne, klasy, funkcje, przestrzenie nazw, itp.) mogą być nazwane przy użyciu jednego z tych trzech stylów, ogólnie mówiąc:
- Camel Case (ex: someVar, someClass, somePackage.xyz).
- Pascal Case (ex: SomeVar, SomeClass, SomePackage.xyz).
- Underscores (ex: some_var, some_class, some_package.xyz).
W camel casing, nazwy zaczynają się od małej litery, ale każde właściwe słowo w nazwie jest pisane wielkimi literami, podobnie jak akronimy. Na przykład, powszechnie używane tokeny w wielu językach, takie jak toString, checkValidity, lineHeight, timestampToLocalDateTime, itp. są przykładami camel casing.
Pascal casing jest podobny do camel casing, z wyjątkiem tego, że pierwsza litera również zaczyna się od dużej litery (SomeClass zamiast someClass).
W underscore casing, wszystko jest pisane małymi literami (nawet akronimy), a słowa są oddzielone podkreślnikami (some_class, some_func, some_var, itp.). Ta konwencja jest również popularnie znana jako obudowa węża.
Ogólna idea jest taka, że możesz używać dowolnej konwencji w swoim projekcie tak długo, jak jesteś konsekwentny w używaniu jej wszędzie. Ale kiedy kodujesz dla dużego projektu lub zespołu, powinieneś dostosować się do normy tego, co jest tam używane. Dlatego warto znać konwencje typowe dla różnych języków programowania.
Powszechną praktyką dla języka w stylu C, takiego jak Java czy JS, jest używanie camelCase dla wszystkich zmiennych i członków obiektów (właściwości & methods), i PascalCase dla nazw klas i konstruktorów. Przestrzenie nazw (lub Pakiety w świecie Java) są zazwyczaj w CamelCase.
Ale niektóre języki robią od tego wyjątek. C#, na przykład, używa PascalCase dla przestrzeni nazw, a nawet metod publicznych. Stąd, główna funkcja (lub punkt wejścia) jest zawsze static void main() w java, ale static void Main() w C# (Zwróć uwagę na kapitalizację słowa „Main”).
Niektóre języki, które nie wywodzą swojej składni z C (takie jak Python & Ruby) używają podkreśleń dla prawie wszystkiego z wyjątkiem nazw klas. Stąd, zawsze jest to sys.base_prefix zamiast sys.basePrefixdatetime zamiast DateTimestr.splitlines() zamiast str.splitLines() w pythonie.
W przypadku standardowej biblioteki pythona zauważyłem, że nawet klasy używają podkreśleń czasami, co jest niespójnością. Na przykład, datetime.datetime jest klasą i tak samo jest csv.excel_tab. Popularne frameworki i biblioteki (takie jak django i flask) używają jednak camel case dla klas.
Podobna niekonsekwencja występuje w PHP. Język ewoluuje od podkreślników do wielbłądów w ostatnich latach, ale niektóre stare tokeny wciąż prześladują ten język. Na przykład, mysqli::set_local_infile_default vs PDOStatement::debugDumpParams.
Więc, ostatecznie, wszystko sprowadza się do twoich własnych preferencji, kiedy rozpoczynasz projekt. Ale pomaga wiedzieć, jakie są zazwyczaj stosowane konwencje w popularnych projektach open source w języku, który preferujesz.
Uaktualnienie
Jest też czwarty przypadek, na który zwrócił uwagę @ovais, mianowicie przypadek kebaba. Jest on bardzo podobny do obudowy podkreślenia, z wyjątkiem tego, że podkreślenia są zastępowane myślnikami (kreskami). Tak więc, some_func staje się some-func, co jest oczywiście niedozwolone, ponieważ myślnik nie jest używany do nazywania tokenów, ponieważ jest już wbudowany dla operatora minus w większości języków programowania. Tam gdzie kebab case jest używany najczęściej, to do tworzenia klas w arkuszach stylów css! Nazwy takie jak main-divmain-navbar i article-footer są powszechnie używane przez twórców stron internetowych podczas pisania ich HTML/CSS. Ta konwencja jest w zasadzie przypadkiem kebaba.
Update
Jak mówi @patrykrudnicki, stałe są obsługiwane inaczej. Z mojego doświadczenia wynika, że pełne podkreślenia (SOME_CONST) to popularna konwencja dla stałych w wielu językach, w tym Java, PHP i Python.
Update
Podsumowując, jest to typowa lub ogólnie przestrzegana konwencja w najczęściej używanych językach programowania open source:
| Token | python | Java/JS | PHP |
|---|---|---|---|
| zmienna | under_score | camelCase | mix (zmierzający w kierunku camelCase) |
| funkcja | under_score() | camelCase() | mix (zmierzający w kierunku camelCase()) |
| constant | UNDER_SCORE | UNDER_SCORE | UNDER_SCORE |
| class | PascalCase | PascalCase | mix (zmierzający w kierunku PascalCase) |
| namespace | under_score | camelCase | mix (zmierzający w kierunku PascalCase) |
Kilka pomocnych linków:
- https://softwareengineering.stackexchange.com/questions/196416/whats-the-dominant-naming-convention-for-variables-in-php-camelcase-or-undersc
- https://stackoverflow.com/questions/149491/pascal-casing-or-camel-casing-for-c-sharp-code
- https://www.c-sharpcorner.com/forums/when-to-use-camel-case-and-pascal-case-c-sharp
- https://softwareengineering.stackexchange.com/questions/53498/what-is-the-philosophy-reasoning-behind-cs-pascal-casing-method-names