dużo szybciej niż ' IThinkTheyAreBothAboutTheSame '. ' Jestem prawie pewien, że można to udowodnić naukowo. 🙂
@John Isaacks: I ' przykro mi to zgłosić (jako zwolennik spod znaku), że jedno badanie wykazało, że " osłonka wielbłąda prowadzi do większej dokładności wśród wszystkich badanych, niezależnie od treningu " .
IWonderWhetherReadingEnglishWrittenInOneStyleVersusAnotherMakesMuchDifference. InTheEnd, IFindThatNeitherIsVeryGoodAtBeingEasyToRead. It_screws_horribly_with_line_length_and_makes_even_the_simplest_thing_complicated. I_wonder_whether_there_would_be_language_support_in_the_future_for_quoted_variable_names. " Moim zdaniem miałoby to o wiele więcej sensu niż camelCase lub underscore_separators ".
Odpowiedź
Zgadzam się, że w pewnym stopniu zależy to od języka, którego „używasz; kod ma tendencję do ładniejszego wyglądu, gdy nazwy symboli mają to samo formatowanie reżim jako wbudowane i podstawowe biblioteki języka.
Ale tam, gdzie jest wybór, wolę podkreślenia od wielbłądów, z jednego prostego powodu: uważam, że ten styl jest łatwiejszy do odczytania. Oto przykład: co uważasz za bardziej czytelne? To:
aRatherLongSymbolName
lub to:
a_rather_long_symbol_name
Wydaje mi się, że wersja z podkreśleniem jest znacznie łatwiejsza czytać. Mój mózg może zignorować podkreślenia znacznie łatwiej niż wykryć granice małych / wielkich liter w przypadku wielbłąda, zwłaszcza gdy granice są między glifami, które wyglądają podobnie do innych glifów z przeciwnej litery, lub cyframi (I/l, O/0, t/I itd.). Na przykład ta zmienna boolowska przechowuje wartość wskazującą, czy Igloo zostało zbudowane z odpowiednim pozwoleniem na planowanie (niewątpliwie powszechny przypadek użycia dla nas wszystkich):
isIllicitIgloo
Uważam, że ta wersja jest dużo łatwiejsza do odczytania:
is_illicit_igloo
Może nawet gorsza niż trudna do odczytania nazwa symbolu to łatwa do błędnego odczytania nazwa symbolu. Dobre nazwy symboli są samodokumentujące, co dla mnie oznacza, że powinieneś być w stanie je odczytać i zrozumieć ich znaczenie na pierwszy rzut oka. (Jestem pewien, że wszyscy czytamy wydruki kodów w łóżku dla przyjemności, ale czasami też żartujemy w pośpiechu). Często przy nazwach symboli wielbłądów stwierdzam, że łatwo jest je źle odczytać i odnieść złe wrażenie semantyki symbolu.
Komentarze
Odpowiedź
Myślę, że powinieneś użyć konwencji nazewnictwa przyjętej na twojej platformie. underscore_case będzie wyglądać dziwnie w kodzie C #, tak jak camelCase w Ruby =)
Komentarze
Odpowiedź
Szczerze, to nie ma znaczenia, o ile wszyscy w zespole używają ten sam schemat. Są szanse, że jedna lub druga jest dla Ciebie bardziej naturalna, chociaż prawdziwe znaczenie ma czytelność kodu na dłuższą metę, a wtedy ważne jest, aby wszyscy przestrzegali tych samych zasad nazewnictwa.
Komentarze
Odpowiedz
Na podstawie odpowiedzi Johna Isaacksa:
„Szczerze mówiąc, kod jest łatwiejszy do odczytania” Opinia czy fakt?
Zdecydowałem się poszukać informacji i znalazłem ten artykuł . Co nauka ma do powiedzenia na ten temat?
- Osłona wielbłąda ma większe prawdopodobieństwo poprawności niż podkreślenia. (kurs jest wyższy o 51,5%)
- Sprawa wielbłąda trwała średnio 0,42 sekundy dłużej , czyli 13,5% dłużej.
- Trening nie ma statystycznie istotnego wpływu na to, jak styl wpływa na poprawność.
- Osoby z były szybsze na identyfikatorach w stylu wielbłąda.
- Trening w jednym stylu, negatywnie wpływa na czas znajdowania dla innych stylów.
W moim poście na blogu na ten temat, przeglądam artykuł naukowy i wyciągnij następujący wniosek.
Tylko powolność przypadku wielbłąda ( 2) jest naprawdę istotne dla programowania, pomijając pozostałe 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źć w poście na blogu.
Ciekaw jestem, jak ten artykuł może zmienić czyjąś opinię. 🙂
Komentarze
Odpowiedź
Skopiuj najmądrzejszych facetów
W przypadku języków programowania, skopiuj styl programisty języka.
Na przykład koduję C dokładnie tak, jak jest to zrobione w K & R.
Następnie kiedy ktoś próbuje zacząć nudne kodowanie stylu rozmowy, mogę im powiedzieć „porozmawiaj o tym z Dennisem Ritche i daj mi znać, co on mówi”.
Komentarze
Answer
Ogólnie wolę camelCase. Jest to jednak spowodowane tym, że większość mojej kariery zawodowej pracuję w językach i środowiskach, w których przewodnicy stylów zwykle zalecają camelCase. (Java, ECMAScript, C ++). Ty, będąc osobą PHP, prawdopodobnie będziesz miał odwrotne preferencje.
To powiedziawszy, kiedy wychodzisz poza trzy lub cztery słowa, lub jeśli używasz inicjalizacji, takich jak XMLForExample, przestaje być tak czytelne.
Dlatego emacs daje nam tryb okularów.
Komentarze
Odpowiedź
camelCase
Jest to jedno z niewielu miejsc, w których zawsze będę wybierać„ umiejętność pisania ”zamiast czytelności. CamelCase jest po prostu łatwiejszy do pisania, a bycie milszym dla moich palców wygrywa z niewielkim wzrostem czytelności.
zakładając oczywiście, że projekt nie jest oparty na istniejącej bazie kodu o innym standardzie.
Komentarze
- Nie ' Nie zgadzam się z tym, piszesz kod tylko raz, ale potem musisz go czytać wiele razy.
Odpowiedź
To interesujące pytanie, o którym myślałem wiele razy. Myślę, że nie ma jednoznacznej odpowiedzi.
Zgodnie z konwencjami „kulturowymi” to dobry wybór. „Kulturalne” w tym przypadku oznacza konwencje ustalone w zespole / firmie i zasadniczo zawierają one również konwencje językowe / platformowe. Pomaga innym w łatwym czytaniu / używaniu twojego kodu i nie wymaga dodatkowego wysiłku i czasu, aby zrozumieć twój kod.
Czasami warto złamać akceptowane zapisy. Jeden z moich małych projektów (w Pythonie) Użyłem underscored_names do funkcji narzędziowych / metod „chronionych” oraz methodNames w stylu Java do metod. Mój zespół był zadowolony z nim 🙂
Odpowiedź
Zależy od języka programowania.
Rozważam użycie wielkości liter w ta sama łódź, w której można używać notacji węgierskiej:
- Python: underscore_case, bez notacji węgierskiej
- C ++: camelCase, notacja węgierska
Komentarze
Odpowiedź
Oba!
Dużo pracuję nad CakePHP i używam albo CamelCase, albo $underscored_vars w następujący sposób (nawet poza projektami CakePHP):
- nazwy plików –
/lowercased_underscored.php Typowe, ale warte wspomnienia.
- klasy –
class CamelCase extends ParentObject. Zauważ, że w przypadku używania CamelCase, początkowy znak nie jest małą literą. Uważam, że camelCase wygląda naprawdę dziwnie.
- zmienne –
$are_variables_underscored === TRUE;
- zmienne przechowujące instancje –
$CamelCase = new CamelCase();
- klucze tablicy –
$collection["underscored_keys"];
- stałe – myślę każdy może zgodzić się, że stałe powinny być
ALL_CAPS_AND_UNDERSCORED.
- metody –
$CamelCase->foo_method_underscored();
- metody statyczne –
CamelCase::just_like_regular_methods();
Komentarze
Odpowiedź
Osobiście wolę underscore_case ponieważ uważam, że jest bardziej czytelny, ale zgadzam się z innymi respondentami, którzy wskazują, że spójność z istniejącą bazą kodów jest znacznie ważniejsza.
Mam jednak kontrprzykład dla tych, którzy mówią „ postępuj zgodnie z konwencją swojego języka i jego bibliotek ”.
W przeszłości pisaliśmy kod C w systemie Windows za pomocą underscore_case i nazywaliśmy go PascalCase Funkcje Win32:
if (one_of_our_conditions_is_true()) { call_one_of_our_functions(); CallSystemFunction(); }
Wizualne rozróżnienie między naszymi nazwami funkcji a nazwami funkcji Microsoftu było raczej pomocą niż przeszkodą, ponieważ wyraźnie pokazał, kiedy kod trafia do „krainy systemu”.
Ponadto mogłem zmienić reguły podświetlania składni mojego edytora, aby wyświetlać je w różnych kolorach, co dawało dalsze wskazówki wizualne, gdy próbowałem rozumieć nieznane fragmenty kodu (lub nawet własne).
Odpowiedź
Naprawdę lubię zwykłe-myślniki Dylana, ponieważ są-łatwe-do-wpisania-i-łatwe -to-read.
Like
result-code := write-buffer(file-stream, some-string)
Ale myślę, że ponieważ ten język jest dość niejasny, jest to trochę nie na temat. .. 🙁
Komentarze
Odpowiedź
Na uniwersytecie nauczono mnie używać camelCase. W ciągu ostatnich kilku lat stosowałem kilka różnych konwencji, ale wolę camelCase niż cokolwiek innego. Myślę, że pamiętam, że czytałem gdzieś, że camelCase jest najłatwiejszy do przeczytania i zrozumienia.
Komentarze
Odpowiedź
Jak wspomniała większość ludzi – użyj istniejącego standardu. Jeśli jest to nowy projekt, użyj standardu języka i frameworków, których będziesz używać.
I nie daj się zmylić, nie chodzi o czytelność (która jest subiektywna), chodzi o konsekwencję i profesjonalizm. Każdy, kto pracował w oparciu o kod z wieloma „standardami”, zrozumie.
Odpowiedź
Czasami używam mieszanki: nazwa_funkcji_modułu. Wszystkie (niestatyczne) funkcje w moich modułach zaczynają się od skrótu modułu.
Na przykład funkcja wysyłająca zawartość bufora na magistrali I2C:
i2c_BufferSend()
Alternatywa i2c_buffer_send nie wykazuje wystarczająco dużej separacji między prefiksem a nazwą funkcji. i2cBufferSend miesza w zbyt duży prefiks (w tym module jest całkiem sporo funkcji I2C).
i2c_Buffer_send mogłoby być alternatywą.
Odpowiadam, że dostosowujesz się do tego, co najlepiej pasuje do twojego projektu (twojego języka, twojej architektury SW, …) i chciałem zwrócić uwagę, ż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.
Komentarze
Odpowiedź
Osobiście , Wolę camelCase, ale myślę, że w niektórych czcionkach podkreślenia są łatwiejsze do odczytania.
Sugerowałbym, że jeśli potrzebujesz przedrostków do rozróżniania 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 potrzebujesz rozróżniać typy, dlaczego nie użyć języka, który na to pozwala?
var intThingy = 7; // :( int thingy = 7; // :)
Kiedy już to zrobisz i „nie używasz tylko nazwy jako metadanych, nie będziesz mieć wystarczająco długich nazw, aby ma ogromne znaczenie, czy wolisz dodatkowe naciśnięcie klawisza, czy nie.
Komentarze
Odpowiedź
Na początku zgadzam się z dafmetal . Niezwykle ważne jest, aby nie mieszać różnych stylów programowania. Robienie tego w jednym i tym samym pliku to najgorsze, co możesz zrobić IMHO. W przypadku różnych plików jest to rozpraszające, ale nie śmiertelne.
Następną rzeczą, którą musisz zrobić, jest nazwanie reguł popularnych dla języka, w którym piszesz. Mój kod C ++ dla instnace oczywiście wygląda inaczej niż coś dla Pythona (PEP8 jest tutaj fajnym przewodnikiem)
Możesz także używać różnych konwencji nazewnictwa, aby odnosić się do różnych rzeczy, tak samo jak prawdopodobnie używasz UPPER_CASE dla stałych (dotyczy to tylko niektórych języki oczywiście), możesz użyć this_style dla lokalnych nazw zmiennych, podczas gdy możesz użyć camelCase dla zmiennych instancji / składowych. Może to nie być potrzebne, jeśli masz takie rzeczy, jak self lub this.
Aktualizacja
Weźmy przypadek, w którym masz platformę. Foo witch nie zaleca żadnych konwencji nazewnictwa i wybór jednej z nich należy do lidera zespołu. Jesteś liderem zespołu, dlaczego miałbyś wybrać camelCase lub dlaczego underscore_case.
Tak naprawdę nie ma żadnej przewagi nad drugim. Ta sprawa jest bardzo subiektywna i raz uzgodniona nie będzie miała znaczenia. Zawsze toczą się religijne wojny o te małe rzeczy. Ale kiedy już się do nich przyzwyczaisz, dyskusje wydają się całkowicie zbędne.
Cytując Alexa Martellego w bardzo podobnej sprawie:
Jasne, w Rubim męczę się wpisywaniem głupiego „końca” na końcu każdego bloku (zamiast po prostu bez wcięcia) – ale potem unikam wpisywania równie głupiego „:”, które Python wymaga początku każdego bloku, więc jest to prawie pranie :-). Inne różnice w składni, takie jak „@foo” i „self.foo”, lub większe znaczenie wielkości liter w Ruby kontra Python są dla mnie tak samo nieistotne.
Inni bez wątpienia opierają swój wybór języków programowania właśnie na takich kwestiach i generują najgorętsze debaty – ale dla mnie to tylko przykład jednego z praw Parkinsona w akcji ( kwota debaty na dany temat jest odwrotnie proporcjonalna do rzeczywistego znaczenia sprawy ).
Źródło
Jeśli jesteś liderem zespołu, po prostu wybierz jednego. Ponieważ jedna nie ma żadnej przewagi nad drugą, możesz po prostu rzucić kostką lub wybrać to, co lubisz bardziej.
Odpowiedź
Czytałem kilka lat temu, że programiści, którzy nie mówią po angielsku jako pierwszym języku, zwykle uważają, że podkreślenie jest łatwiejsze do zrozumienia, ale nie mogę znaleźć odniesienia i nie mam pojęcia, czy to prawda.
Odpowiedź
W przypadku języków programowania, których używałem, takich jak Java, Python, C ++, przyjąłem przejrzysty format:
- ClassNamesArePascalCase
- methodNamesAreCamalCase
- variable_names_are_underscore
- CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES
To pozwala mi natychmiast zorientuj się, z czym mam do czynienia. Odkryłem, że jest to przydatne dla siebie i powinno być łatwe do naśladowania dla kogoś innego czytającego kod. Myślę, że tak jak inni wspominali, najważniejsza jest spójność. Dlatego uważam, że mój format być wystarczająco prostym w utrzymaniu, zapewniając jednocześnie wyraźne rozróżnienie między typami nazw. Mogę sobie wyobrazić interface_Names_Are_Like_This i Abstract_Classes_Are_Like_Th jako możliwe rozszerzenia, ale wydaje się, że jest to bardziej skomplikowane do naśladowania i może nie być tak przydatne do rozróżnienia.
Zauważyłem również, że przydatne jest bycie ścisłym i nazywanie rzeczy w PascalCase, takich 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łędnej pisowni takich rzeczy, 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_with_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ąć 4a 4a diva „private pola. W innych formatach widziałem przedrostek „m”, ale te formaty również używają camelCase dla nazw zmiennych. Pozwala mi to również na rozróżnienie między polami, do których należy mieć dostęp tylko wewnętrznie przez klasę (i sprawiając, że super jest jasne, gdy dzieje się poza zajęciami object._field_x wyróżnia się).
Odpowiedź
Gdyby to zależało ode mnie, nie wymuszałbym ani nie sugerowałbym użycie dowolnego 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 analizowanie symbolu nie jest wielkim narzutem w dużym schemacie rzeczy.
Myślę, że głównym argumentem przemawiającym za konwencją jest to, że wiesz z góry, jaki jest format nazwy funkcji / zmiennej i nie musisz jej sprawdzać – czy to LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Teraz sprzeciwiłbym się temu argumentowi mówiąc: „Zdobądź IDE, które obsługuje automatyczne uzupełnianie w stylu Intellisense!” (choć nie zawsze jest to możliwe).
Ostatecznie jednak nie ma znaczenia, jakiego stylu użyjesz, ponieważ kompilator / interpreter nie obchodzi. Ważne jest to, że nazwa jest przydatna:
NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon
Trzy różne style, ale wiesz dokładnie, do czego służą.
Komentarze
Odpowiedź
Może wydawać się głupie, ale nie lubię podkreśleń, ponieważ podkreślenie jest cienkie i ukrywa się w tekście wielowierszowym i tęsknię za tym. Ponadto w niektórych (wielu) edytorach tekstu i / lub środowiskach programistycznych po dwukrotnym kliknięciu nazwę tokena, aby go podświetlić, aby go skopiować lub przeciągnąć i upuścić, system nie podświetli całego tokena, a jedynie podświetli jedną część tokena między sąsiednimi podkreśleniami. To mnie doprowadza do szału.
Odpowiedź
Zwykle wolę camelCase z głupiego powodu, że większość prac programistycznych wykonuję w Eclipse (dla Java, PHP i JavaScript), a kiedy Ctrl + ← lub Ctrl + → poprzez słowa, faktycznie zatrzymuje się na granicach camelCase.
Tj .: myIntVariable będzie traktowane przez Eclipse jako 3 słowa, gdy Ct rl + ← → ” przez to.
Wiem, że to dziwne dziwactwo, ale wolę edytować środkowe słowa w nazwie CamelCase.