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
Odpowiedzi:
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:
albo to:
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):Ta wersja jest dla mnie dużo łatwiejsza do odczytania:
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.
źródło
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 =)
źródło
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.
źródło
Na podstawie odpowiedzi odpowiedź Johna Isaacksa:
Postanowiłem przeprowadzić badania i znalazłem ten artykuł . Co nauka ma do powiedzenia na ten temat?
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. :)
źródło
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”.
źródło
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?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.
źródło
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.
źródło
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_names
funkcji narzędziowych / metod „chronionych” oraz metod w stylu JavamethodNames
. Mój zespół był z tego zadowolony :)źródło
Zależy od języka programowania.
Zastanawiam się nad użyciem tej skrzynki na tej samej łodzi, czy używać notacji węgierskiej:
źródło
XMLHttpRequest
<- Nienawidzę tego imienia z pasją.Obie!
Dużo rozwijam w CakePHP i używam albo,
CamelCase
albo$underscored_vars
w następujący sposób (nawet poza projektami CakePHP):/lowercased_underscored.php
typowe, ale warte wspomnienia.class CamelCase extends ParentObject
. Pamiętaj, że podczas używaniaCamelCase
początkowy znak nie jest pisany małymi literami. Wydaje mi się, żecamelCase
wyglądam naprawdę dziwnie.$are_variables_underscored === TRUE;
$CamelCase = new CamelCase();
$collection['underscored_keys'];
ALL_CAPS_AND_UNDERSCORED
.$CamelCase->foo_method_underscored();
CamelCase::just_like_regular_methods();
źródło
Osobiście wolę,
underscore_case
ponieważ 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_case
i nazywaliśmyPascalCase
funkcje Win32: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).
źródło
Naprawdę lubię po prostu normalne myślniki Dylana, ponieważ są one łatwe do pisania i czytania.
Lubić
Ale wydaje mi się, że ponieważ ten język jest dość niejasny, jest to trochę nie na temat ... :(
źródło
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.
źródło
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.
źródło
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:
Alternatywa
i2c_buffer_send
nie pokazuje wystarczająco dużej separacji między prefiksem a nazwą funkcji.i2cBufferSend
za 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.
źródło
Motor1_Start()
,Motor2_Start()
,Motor1_Stop()
iMotor2_Stop()
mają związek, który może być mniej oczywiste, bez podkreślenia.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.
Podobnie, jeśli chcesz rozróżnić typy, dlaczego nie użyć języka, który im na to pozwala?
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.
źródło
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
self
lubthis
jednak.Aktualizacja
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:
Ź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.
źródło
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.
źródło
W przypadku języków programowania, których używałem, takich jak Java, Python, C ++, przyjęłem przejrzysty format:
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 klasaobject._field_x
wyróżnia się).źródło
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:
Trzy różne style, ale dokładnie wiesz, co każdy z nich robi.
źródło
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.
źródło
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:
myIntVariable
był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.
źródło