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

70

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

poelinca
źródło
6
„szczerze mówiąc, kod jest łatwiejszy do odczytania” Opinia czy fakt?
JD Isaacks,
9
IThinkTheyAreBothAboutTheSame but_i_think_mixing_them_is_pretty_bad.
dietbuddha,
7
@dietbuddha: Właśnie przeczytałem „but_i_think_mixing_them_is_pretty_bad” dużo szybciej niż „IThinkTheyAreBothAboutTheSame”. Jestem prawie pewien, że można to udowodnić naukowo. :)
Steven Jeuris,
@John Isaacks: Z przykrością informuję (jako niewolnik), że w jednym z badań stwierdzono, że „obudowa wielbłąda prowadzi do większej dokładności wśród wszystkich osób bez względu na szkolenie” .
Steven Jeuris,
IWonderWhetherReadingEnglishWrittenInOneStyleVersusAnotherMakesMuchDifference. InTheEnd, IFindThatNeitherIsVeryGoodAtBeingEasyToRead. To_skręty_historycznie_z_linią_długości_i sprawia, że ​​nawet_na_prosta_skomplikowana. I_wonder_whether_there_would_be_language_support_in_the_future_for_quoted_variable_names. „Moim zdaniem byłoby to o wiele bardziej sensowne niż camelCase lub underscore_separators”.
Christopher Mahan

Odpowiedzi:

84

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.

Simon Whitaker
źródło
25
Jeden problem z podkreśleniami: użyteczność. W przypadku większości klawiatur (europejskich) wpisanie znaku podkreślenia wymaga przytrzymania klawisza SHIFT. Musisz to zrobić również dla camelCase, ale mogę wygodnie przytrzymać klawisz SHIFT za pomocą pinky i wpisać dowolną literę - ale ponieważ klawisz podkreślenia znajduje się tuż obok klawisza SHIFT, naciśnięcie obu jednocześnie jest raczej niewygodne i przerywa przepływ pisania.
LearnCocos2D,
11
W przypadku pierwszego z nich uważam, że camelCase jest łatwiejszy do odczytania - choć ten drugi jest oczywiście inny.
Phoshi,
19
To zależy od tego, do czego jesteś przyzwyczajony. Uważam, że camelCases są łatwiejsze do odczytania, a poza tym są krótsze niż równoważne nazwy podkreślenia.
Joonas Pulakka
17
I hate wpisując podkreślenia.
EpsilonVector,
6
Punkt „użyteczność” nie ma w tym przypadku znaczenia. Kod jest zwykle zapisywany tylko raz przez jedną osobę, ale powiedzmy w kolejności od 1 do 10 razy, z uwzględnieniem edycji i potencjalnego programowania par. Ale kod jest zwykle odczytywany kilkadziesiąt / setki / tysiące razy przez jedną lub potencjalnie wiele osób. Dlatego ułatwienie odczytu kodu jest o kilka wielkości ważniejsze niż łatwe do napisania kodu.
hlovdal
97

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 =)

Aleksiej Anufrijew
źródło
23
Spójność jest kluczem. Niezależnie od tego, czy zgadzasz się z lokalną konwencją, czy nie, ułatwisz sobie (i wszystkim innym) swój czas, zachowując spójność. (Chyba że lokalna konwencja sama w sobie jest niespójna.) Również czytelność jest w większości fałszywym argumentem: przeczytaj wystarczający kod, jeśli zauważysz, że istnieje niewielka różnica, chyba że zdecydujesz, że jest nieczytelna.
Richard,
1
W pełni zgadzam się. Po prostu uważam, że lepiej jest stosować konwencje platformy zamiast niestandardowych, ponieważ na przykład nowi faceci w zespole będą się z tym czuli swobodniej.
Alexey Anufriyev,
2
Ale biada tym z nas, którzy pracują na dwóch platformach z dwiema konwencjami, gdzie niektórzy wolą, a inni wolą drugą!
Michael K,
Jeśli platforma ma 2 konwencje, poprosiłbym wszystkich członków zespołu, aby głosowali na konwencję, z którą czują się komfortowo =)
Alexey Anufriyev,
20

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.

dafmetal
źródło
masz całkowitą rację, jednak staram się dowiedzieć, jaka opinia ludzi na temat wiedźmy byłaby lepsza (powiedzmy dla całego zespołu) i dlaczego ... podczas gdy rozumiem, że niektórzy ludzie mogą być przyzwyczajeni do jakiejś konwencji lub inni czują się bardziej naturalnie z drugim.
poelinca
20

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. :)

Steven Jeuris
źródło
3
Oczywiście odrzucasz wszystkie inne punkty z powodu preferencji dla podkreślników, a inne punkty nie pomagają w twojej sprawie ...
Charles Boyung
2
@Charles: Tak i nie, IMHO robię dobre argumenty, dlaczego można je odrzucić, a niektóre z nich są nawet omawiane jako problematyczne przez sam artykuł. Dokument uzupełniający bada niektóre problemy tego artykułu , a wyniki są podkreślone.
Steven Jeuris
11

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”.

Mark Harrison
źródło
12
Oryginał nie zawsze jest najlepszy. W księdze ewangelii K&R na C jest wiele złych praktyk. Zanim rozpocznie się wojna z płomieniami ... przeczytaj niektóre z rekomendacji MISRA.
szybko_niedz.
10
Nie zapominaj, że K&R został napisany, gdy nie było żadnych GUI-IDE. Większość pracy wykonano na terminalach 80x25 znaków, więc miejsce na ekranie było na wagę złota, if (...) {oszczędzając linię! W dzisiejszych czasach jest więcej miejsca na ekranie - czy K&R byłby inny, gdyby został napisany dzisiaj z IDE GUI w wysokiej rozdzielczości i wieloma konfiguracjami monitorów?
Skizz,
3
Tak, ale kiedy ktoś mówi, że koduje C jak K&R, dostaje rekwizyty za bycie oldschoolowym.
Christopher Mahan,
3
@ quickly_now, przywołaj to z Dennisem Ritchiem i daj mi znać, co on mówi!
Mark Harrison,
Przyjmuję dużo formatowania z MS: _internalToClassOnly, availableByGetter, PublicVariable.
IAbstract
10

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.

Paul Butcher
źródło
2
+1 za zmuszenie mnie do odkrycia trybu okularów! Właśnie przetestowałem go na pliku kodu, który używa camelCase, i zauważyłem, jak od razu zaczął wyglądać lepiej (montaż z mnóstwem etykiet w camelCase).
Gauthier,
Okej, co to jest tryb okularów?
Marcie,
8

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.

rev AShelly
źródło
Nie zgadzam się z tym, piszesz kod tylko raz, ale potem musisz go przeczytać wiele razy
Roman Pekar
7

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 :)

duros
źródło
6

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
Lionel
źródło
8
@Kevin Cantu: Właściwie nazwa Javascript jest w PascalCase, a nie w camelCase ...
Guffa,
1
@Guffa: touché!
Kevin Cantu,
2
@Kevin Cantu: on JavaScript: XMLHttpRequest<- Nienawidzę tego imienia z pasją.
Thanatos,
1
hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
Kevin Cantu
4
@Lionel: W rzeczywistości notacja węgierska prawie nigdy nie jest używana w C ++, ponieważ C ++ już sprawdza twoje typy. To bardziej artefakt historyczny niż cokolwiek innego.
In silico
6

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();
Stephen
źródło
3
muszę się z tobą zgodzić, że pierwsza postać ma małe litery doprowadza mnie do szału! Nienawidzę camelCase z pasją.
HLGEM
W Javie, gdzie nazwy są zwykle wielbłądem, nazwy klas zaczynają się od dużej litery. Ma to na celu odróżnienie ich od nazw metod.
James P.
5

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).

Paul Stephenson
źródło
5

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 ... :(

Kosta
źródło
3
Jestem też zmęczony naciskaniem klawisza shift do pisania podkreślników.
Gauthier,
8
Zwykle nie jest to możliwe w przypadku nazw zmiennych, ponieważ „-” zwykle oznacza minus.
Eric Wilson,
4

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.

Ross
źródło
4
cóż, nie jest to łatwiejsze, ponieważ gdzieś czytasz, jest łatwiejsze, ponieważ był to pierwszy, z którym pracowałeś, a przede wszystkim dlatego, że jesteś do tego bardziej przyzwyczajony, na przykład bardziej komfortowo jest mi underscore_case.
poelinca
1
jak już czytałem, że badanie zostało wykonane i okazało się, że jest lepsze ..
Ross,
4

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.

Colin Goudie
źródło
4

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.

Gauthier
źródło
1
+1 za ostatnie 2 wiersze, jednak nie polecam łączenia konwencji nazewnictwa, powinieneś trzymać się jednego lub drugiego.
poelinca
Dopóki konwencja jest dobrze zdefiniowana (prefiks + podkreślenie + PascalCase) ...
Gauthier
Lubię używać podkreślników do oddzielania części nazwy, które mają semantycznie rozłączne cele, szczególnie jeśli podobieństwo obu części może być znaczące. Na przykład, procedury Motor1_Start(), Motor2_Start(), Motor1_Stop()i Motor2_Stop()mają związek, który może być mniej oczywiste, bez podkreślenia.
supercat
4

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.

Kevin Cantu
źródło
1
Jednym z powodów używania camelCase lub underscore_case jest to, że nie muszę szukać definicji obiektów, aby rozpoznać, co to jest.
Joshua Shane Liberman,
2

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.

phant0m
źródło
2

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.

Ed Harper
źródło
2

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ę).

Dandre Allison
źródło
1

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.

Skizz
źródło
1
Zaczynam się różnić, ważny jest wygląd źródła. Zobacz teorię rozbicia okna „The pragmatycznego programisty”. Różna konwencja nazewnictwa pogarsza wygląd. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
Gauthier
1
@Gauthier: Chociaż zgadzam się z ideą „rozbite okno”, nie sądzę, aby wielkie litery oznaczały „rozbite okno”. Z pewnością przypadkowo ułożony kod, a mój obecny projekt z pewnością zawiera wiele tego, co staram się uporządkować, kiedy tylko mogę.
Skizz,
Zgadzam się. Potrafię równie dobrze czytać wszystkie trzy. To nie ma znaczenia Po prostu używam tego, czego używa plik, potem cokolwiek zaproponuje język (python), a potem cokolwiek, moim zdaniem, projekt będzie najlepiej obsługiwany. (Kiedyś programowałem w gwbasic, i to wszystko było wielkie - stare dobre czasy!)
Christopher Mahan
0

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.

Charles Bretana
źródło
0

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.

Bassam
źródło