Konwencje nazewnictwa: camelCase kontra underscore_case? co o tym myślisz? [Zamknięte]

Używam underscore_case od około 2 lat, a ostatnio przeszedłem na camelCase z powodu nowej pracy (używam późniejszej od około 2 miesięcy i nadal uważam, że underscore_case lepiej nadaje się do dużych projektów, w których bierze udział wielu programistów, głównie dlatego, że kod jest łatwiejszy do odczytania).

Teraz wszyscy w pracy używają camelCase, ponieważ (jak mówią) kod wygląda bardziej elegancko.

Co myślisz o camelCase lub underscore_case

ps proszę wybacz mój zły angielski

Edytować

Najpierw niektóre aktualizacje:

• platformą jest PHP (ale nie oczekuję ścisłych odpowiedzi związanych z platformą PHP, każdy może podzielić się swoimi przemyśleniami na temat tego, który byłby najlepszy w użyciu, dlatego właśnie tu przyszedłem)

• Używam camelCase tak samo, jak zawsze w zespole (tak jak większość z was poleca)

• używamy Zend Framework, który również zaleca camelCase

Kilka przykładów (związanych z PHP):

• Framework Codeigniter zaleca underscore_case i szczerze mówiąc, kod jest łatwiejszy do odczytania.

• ZF poleca camelCase i nie jestem jedynym, który uważa, że ​​kod ZF jest nieco trudniejszy do wykonania.

Więc moje pytanie zostanie przeformułowane:

Weźmy przypadek, w którym masz platformę Foo, która nie zaleca żadnych konwencji nazewnictwa i jest to wybór lidera zespołu. Jesteś liderem zespołu, dlaczego miałbyś wybrać camelCase lub dlaczego underscore_case?

ps dziękuje wszystkim za szybkie odpowiedzi do tej pory

Zgadzam się, że w pewnym stopniu zależy to od używanego języka; kod wydaje się wyglądać ładniej, gdy nazwy symboli są zgodne z tym samym trybem formatowania, co wbudowane w język i biblioteki podstawowe.

Ale tam, gdzie jest wybór, wolę podkreślenia niż futerał na wielbłąda, z jednego prostego powodu: uważam, że ten styl jest łatwiejszy do odczytania. Oto przykład: co uważasz za bardziej czytelne? To:

aRatherLongSymbolName

albo to:

a_rather_long_symbol_name

Uważam, że wersja podkreślona jest znacznie łatwiejsza do odczytania. Mój mózg może ignorować podkreślenia znacznie łatwiej niż można to wykryć granice małe / wielkie w przypadku wielbłąda, zwłaszcza tam, gdzie są granice pomiędzy glifów, które wyglądają podobnie do innych glifów w przeciwnym wypadku, lub cyframi ( I/l, O/0, t/I, etc). Na przykład ta zmienna boolowska przechowuje wartość wskazującą, czy Igloo zostało zbudowane z odpowiednim pozwoleniem na planowanie (bez wątpienia powszechny przypadek użycia dla nas wszystkich):

isIllicitIgloo

Ta wersja jest dla mnie dużo łatwiejsza do odczytania:

is_illicit_igloo

Być może nawet gorsze niż trudna do odczytania nazwa symbolu to łatwa do odczytania nazwa symbolu. Dobre nazwy symboli są samo-dokumentujące, co dla mnie oznacza, że ​​powinieneś być w stanie je przeczytać i zrozumieć ich znaczenie na pierwszy rzut oka. (Jestem pewien, że wszyscy z przyjemnością czytamy w łóżku wydruki kodów, ale czasami też spieszymy się w pośpiechu.) Często z nazwami symboli wielbłądów często stwierdzam, że łatwo je źle odczytać i mam złe wrażenie semantyka symbolu.

Myślę, że powinieneś użyć konwencji nazewnictwa przyjętej przez twoją platformę. underscore_case będzie wyglądać dziwnie w kodzie C #, jak camelCase w Ruby =)

Szczerze mówiąc, nie ma to tak naprawdę znaczenia, o ile wszyscy członkowie zespołu stosują ten sam schemat. Szanse są jedno lub drugie jest dla Ciebie bardziej naturalne, choć prawdziwa ważność to czytelność kodu na dłuższą metę, a wtedy ważne jest, aby wszyscy przestrzegali tych samych reguł nazewnictwa.

Na podstawie odpowiedzi odpowiedź Johna Isaacksa:

„szczerze mówiąc kod jest łatwiejszy do odczytania” Opinia czy fakt?

Postanowiłem przeprowadzić badania i znalazłem ten artykuł . Co nauka ma do powiedzenia na ten temat?

1. Obudowa wielbłąda ma większe prawdopodobieństwo poprawności niż podkreślenia. (szanse są o 51,5% wyższe)
2. Średnio sprawa z wielbłądem trwała o 0,42 sekundy dłużej , czyli o 13,5% dłużej.
3. Trening nie ma statystycznie istotnego wpływu na wpływ stylu na poprawność.
4. Osoby z większym przeszkoleniem szybciej identyfikowały się w stylu wielbłąda.
5. Trening w jednym stylu negatywnie wpływa na czas znalezienia innego stylu.

W moim poście na ten temat recenzuję artykuł naukowy i wyciągam następujący wniosek.

Jedynie powolność obudowy wielbłąda (2) jest naprawdę istotna dla programowania, odrzucając inne punkty jako nieistotne ze względu na nowoczesne IDE i większość użytkowników camelCase w badaniu. Dyskusję (wraz z ankietą) można znaleźć na blogu.

Ciekawe, jak ten artykuł może zmienić zdanie. :)

Skopiuj najmądrzejszych facetów

W przypadku języków programowania skopiuj styl twórcy języka.

Na przykład koduję C dokładnie tak, jak w K&R.

Potem, gdy ktoś próbuje rozpocząć nudną rozmowę w stylu kodowania, mogę powiedzieć mu, że „porozmawiaj o tym z Dennisem Ritche i daj mi znać, co mówi”.

Ogólnie wolę camelCase. Wynika to jednak z faktu, że przez większość mojej kariery pracowałem w językach i środowiskach, w których przewodniki stylu zwykle zalecają camelCase. (Java, ECMAScript, C ++). Jako osoba PHP możesz mieć przeciwne preferencje.

To powiedziawszy, kiedy przekroczysz trzyOrFourWords lub użyjesz inicjalizacji takiej jak XmlForExample, przestanie być tak czytelny.

Dlatego emacs daje nam tryb okularów.

camelCase

Jest to jedno z niewielu miejsc, w których zawsze wybieram „umiejętność pisania” zamiast czytelności. CamelCase jest po prostu łatwiejszy do pisania, a bycie milszym dla moich palców wygrywa dla mnie niewielki wzrost czytelności.

zakładając oczywiście, że projekt nie opiera się na istniejącej bazie kodu o innym standardzie.

To interesujące pytanie, zastanawiałem się nad tym wiele razy. Ale myślę, że nie ma jednoznacznej odpowiedzi.

Zgodnie z konwencjami „kulturowymi” jest to dobry wybór. „Kulturowy” w tym przypadku oznacza konwencje ustanowione w zespole / firmie i zasadniczo dotyczą one także konwencji językowych / platform. Pomaga innym w łatwym czytaniu / używaniu twojego kodu i nie wymaga dodatkowego wysiłku i czasu, aby wejść w drogę do zrozumienia twojego kodu.

Czasami interesujące jest łamanie przyjętych notacji. Jeden z moich małych projektów (w języku Python) użyłem underscored_namesfunkcji narzędziowych / metod „chronionych” oraz metod w stylu Java methodNames. Mój zespół był z tego zadowolony :)

Zależy od języka programowania.

Zastanawiam się nad użyciem tej skrzynki na tej samej łodzi, czy używać notacji węgierskiej:

• Python: underscore_case, brak notacji węgierskiej
• C ++: camelCase, notacja węgierska

Obie!

Dużo rozwijam w CakePHP i używam albo, CamelCasealbo $underscored_varsw następujący sposób (nawet poza projektami CakePHP):

1. nazwy plików - /lowercased_underscored.phptypowe, ale warte wspomnienia.
2. zajęcia - class CamelCase extends ParentObject. Pamiętaj, że podczas używania CamelCasepoczątkowy znak nie jest pisany małymi literami. Wydaje mi się, że camelCasewyglądam naprawdę dziwnie.
3. zmienne -$are_variables_underscored === TRUE;
4. zmienne przechowujące instancje -$CamelCase = new CamelCase();
5. klucze tablicy -$collection['underscored_keys'];
6. stałe - myślę, że każdy może się zgodzić, że stałe powinny być ALL_CAPS_AND_UNDERSCORED.
7. metody -$CamelCase->foo_method_underscored();
8. metody statyczne -CamelCase::just_like_regular_methods();

Osobiście wolę, underscore_caseponieważ uważam to za bardziej czytelne, ale zgadzam się z innymi użytkownikami, którzy podkreślają, że spójność z istniejącą bazą kodów jest znacznie ważniejsza.

Mam jednak kontrprzykład dla tych, którzy mówią: „przestrzegaj konwencji twojego języka i jego bibliotek”.

W przeszłości pisaliśmy kod C w systemie Windows underscore_casei nazywaliśmy PascalCasefunkcje Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

Wizualne rozróżnienie między nazwami naszych funkcji a nazwami funkcji Microsoftu było raczej pomocą niż przeszkodą, ponieważ wyraźnie pokazało, kiedy kod wkraczał w „obszar systemu”.

Ponadto mogłem zmienić reguły podświetlania składni mojego edytora, aby wyświetlać je w różnych kolorach, co dawało dodatkowe wskazówki wizualne, gdy próbowałem zrozumieć nieznane sekcje kodu (a nawet własne).

Naprawdę lubię po prostu normalne myślniki Dylana, ponieważ są one łatwe do pisania i czytania.

Lubić

result-code := write-buffer(file-stream, some-string)

Ale wydaje mi się, że ponieważ ten język jest dość niejasny, jest to trochę nie na temat ... :(

Na uniwersytecie uczono mnie używania camelCase. W ciągu ostatnich kilku lat stosowałem kilka różnych konwencji, ale wolę camelCase od czegokolwiek innego. Chyba pamiętam gdzieś, że camelCase jest najłatwiejszy do odczytania i zrozumienia.

Jak wspomniano większość osób - skorzystaj z istniejącego standardu. Jeśli jest to nowy projekt, użyj standardu języka i ram, których będziesz używać.

I nie mylcie się, nie chodzi tu o czytelność (co jest subiektywne), chodzi o konsekwencję i profesjonalizm. Każdy, kto pracował w bazie kodu z licznymi „standardami”, zrozumie.

Czasami używam miksu: nazwa_funkcji_modułu. Wszystkie (niestatyczne) funkcje w moich modułach zaczynają się od skrótu modułu.

Na przykład funkcja wysyłania zawartości bufora na magistrali I2C:

i2c_BufferSend()

Alternatywa i2c_buffer_sendnie pokazuje wystarczająco dużej separacji między prefiksem a nazwą funkcji. i2cBufferSendza dużo miksuje w prefiksie (w tym module jest sporo funkcji I2C).

i2c_Buffer_send może być alternatywą.

Moja odpowiedź jest taka, że ​​dostosowujesz się do tego, co najlepiej pasuje do twojego projektu (twój język, architektura SW, ...), i chciałem zauważyć, że mieszanie tych stylów może być przydatne.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Osobiście wolę camelCase, ale w niektórych czcionkach myślę, że podkreślenia są łatwiejsze do odczytania.

Sugerowałbym, że jeśli potrzebujesz użyć prefiksów do rozróżnienia zestawów zmiennych, powinieneś użyć języka, który pozwala tworzyć przestrzenie nazw lub obiekty lub coś do przechowywania tych informacji.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Podobnie, jeśli chcesz rozróżnić typy, dlaczego nie użyć języka, który im na to pozwala?

var intThingy = 7; // :(

int thingy = 7;    // :)

Kiedy już to zrozumiesz i nie będziesz używać nazwy jako metadanych, nie będziesz mieć wystarczająco długich nazw, aby mieć znaczenie, czy wolisz dodatkowe naciśnięcie klawisza, czy nie.

Na początku zgadzam się z dafmetalem. Bardzo ważne jest, aby nie mieszać różnych stylów programowania. Robienie tego w jednym i tym samym pliku jest najgorsze, co możesz zrobić w IMHO. W przypadku różnych plików jest to rozpraszające, ale nie śmiertelne.

Następną rzeczą, którą musisz zrobić, to reguły nazewnictwa, które są popularne dla języka, w którym piszesz. Mój kod C ++ dla instnace będzie oczywiście wyglądał inaczej niż coś dla Pythona (PEP8 jest tutaj dobrym przewodnikiem)

Możesz także stosować różne konwencje nazewnictwa w odniesieniu do różnych rzeczy, ponieważ prawdopodobnie używasz UPPER_CASE dla stałych (dotyczy to oczywiście tylko niektórych języków), możesz użyć this_style dla lokalnych nazw zmiennych, podczas gdy używasz camelCase na przykład / członek zmienne. Może to nie być potrzebne, gdy masz takie rzeczy jak selflub thisjednak.

Aktualizacja

Weźmy przypadek, w którym masz platformę. Foo, która nie zaleca żadnych konwencji nazewnictwa, a wybór lidera zespołu jest jeden. Jesteś liderem zespołu, dlaczego miałbyś wybrać camelCase lub dlaczego underscore_case.

Tak naprawdę nie ma przewagi jednego nad drugim. Ta kwestia jest bardzo subiektywna i po uzgodnieniu nie będzie miała znaczenia. Zawsze toczą się wojny religijne o te małe rzeczy. Ale kiedy już dostosujesz się do jednego z nich, dyskusje wydają się całkowicie zbędne.

Cytując Alexa Martellego w bardzo podobnej sprawie:

Jasne, mam dość znużenia się w Rubim wpisywaniu głupiego „końca” na końcu każdego bloku (zamiast zwykłego cofania) - ale potem unikam wpisywania równie głupiego „:”, którego Python wymaga początek każdego bloku, więc to prawie pranie :-). Inne różnice w składni, takie jak „@foo” w porównaniu do „self.foo” lub wyższe znaczenie wielkości liter w Ruby vs. Python, są dla mnie tak samo nieistotne.

Inni bez wątpienia opierają swój wybór języków programowania na takich właśnie kwestiach i generują najgorętsze debaty - ale dla mnie to tylko przykład jednego z przepisów prawa Parkinsona w działaniu ( kwota na debatę na temat problemu jest odwrotnie proporcjonalna do problemu faktyczne znaczenie ).

Źródło

Jeśli jesteś liderem zespołu, po prostu idź z jednym. Ponieważ jedno nie ma żadnych przewag nad drugim, możesz po prostu rzucać kostkami lub wybierać to, co lubisz bardziej.

Czytałem kilka lat temu, że programiści, którzy nie mówią po angielsku jako pierwszym językiem, łatwiej znaleźć przypadek podkreślenia, ale łatwiej jest mi znaleźć odniesienie i nie mam pojęcia, czy to prawda.

W przypadku języków programowania, których używałem, takich jak Java, Python, C ++, przyjęłem przejrzysty format:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• zmienna_nazwa_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

To pozwala mi natychmiast rozpoznać, z czym mam do czynienia. Odkryłem, że jest to przydatne dla siebie i powinno być łatwe do naśladowania dla kogoś, kto czyta kod. Myślę, że jak wspomniano inni, najważniejsza jest konsekwencja. Uważam więc, że mój format jest wystarczająco prosty do utrzymania, jednocześnie zapewniając wyraźne rozróżnienie między rodzajami nazw. Mogę sobie wyobrazić interface_Names_Are_Like_This i Abstract_Classes_Are_Like_This jako możliwe rozszerzenia, ale wydaje się, że ich stosowanie jest bardziej skomplikowane i może nie jest tak użyteczne rozróżnienie.

Uważam również, że użyteczne jest zachowanie ścisłości i nadawanie nazw elementom PascalCase, takim jak parser HTML jako HtmlParser zamiast HTMLParser lub HTMLparser. Ponieważ uważam, że łatwiej jest zapamiętać ścisłą regułę i zachować wyraźniejsze granice słów (niestety wymaga to błędów w pisowni, takich jak HTML lub SQL). Podobnie z camelCase, htmlParserMethod zamiast HTMLParserMethod lub HTMLparserMethod.

AKTUALIZACJA :

Od tego czasu znalazłem zastosowanie w rozszerzaniu tych reguł o zmienne prywatne. - _private_variable_names_are_prefixed_w_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

W Javie oznacza to, że pola prywatne z definicji znajdują się w innej przestrzeni nazw niż zmienne lokalne, co oznacza, że ​​można pominąć this.pola prywatne. Inne formaty widziałem przedrostek z „ m”, ale te formaty używają również camelCase do nazw zmiennych. To pozwala mi również dokonać rozróżnienia pomiędzy polami, które powinny być dostępne tylko wewnętrznie przez klasę (i uczynienie go bardzo jasne, kiedy to się dzieje poza klasa object._field_xwyróżnia się).

Gdyby to zależało ode mnie, nie wymuszałbym ani nie sugerowałbym użycia określonego stylu, ponieważ jako programiści moglibyśmy odczytać symbol IfItIsInCamelCase lub in_underscore_space lub nawet in_SomeOtherStyle i zrozumieć, co to znaczy. Poświęcenie niewielkiej ilości czasu na parsowanie symbolu nie stanowi wielkiego obciążenia w wielkim schemacie rzeczy.

Myślę, że głównym argumentem za konwencją jest to, że wiesz z góry, jaki jest format nazwy funkcji / zmiennej i nie musisz jej sprawdzać - czy to LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Teraz przeciwstawiłbym się temu argumentowi, mówiąc: „Uzyskaj IDE, które obsługuje automatyczne uzupełnianie w stylu inteligencji!” (nie zawsze jednak możliwe).

Ostatecznie jednak nie ma znaczenia, jakiego stylu używasz, ponieważ kompilator / interpreter tak naprawdę nie obchodzi. Ważne jest, aby nazwa była przydatna:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Trzy różne style, ale dokładnie wiesz, co każdy z nich robi.

Może to wydawać się głupie, ale nie lubię podkreśleń, ponieważ podkreślenie jest cienkie i ukrywa się w tekście wielowierszowym i tęsknię. Ponadto, w niektórych (wielu) edytorach tekstu i / lub środowiskach programistycznych, po dwukrotnym kliknięciu nazwy tokena, aby go podświetlić, aby go skopiować lub przeciągnąć i upuścić, system nie podświetli całego tokena, a jedynie jedną część tokena, między sąsiadującymi znakami podkreślenia. To doprowadza mnie do szału.

Wolę camelCase z tego niemądrego powodu, że większość mojego rozwoju wykonuję w Eclipse (dla Java, PHP i JavaScript), a kiedy Ctrl+ ←lub Ctrl+ →poprzez słowa, faktycznie zatrzymuje się na granicach camelCase.

To znaczy: myIntVariablebyłby traktowany przez Eclipse jako 3 słowa podczas Ctrl+ ← →przechodzenia przez to.

Wiem, że to dziwne dziwactwo, ale wolę edytować środkowe słowa w nazwie camelCase.