Konvence pojmenování: camelCase versus underscore_case? co si o tom myslíš? [uzavřeno]

Souhlasím s tím, že to do určité míry závisí na jazyce, který používáte; kód má tendenci vypadat úhledněji, když se vaše názvy symbolů řídí stejným formátováním režim jako vestavěné a základní knihovny jazyka.

Ale kde je možnost volby, dávám přednost podtržítkům před velbloudem, a to z jednoho prostého důvodu: ten styl se mi čte snadněji. Tady příklad: který je podle vás čitelnější? Toto:

aRatherLongSymbolName 

nebo toto:

a_rather_long_symbol_name 

Podtržítkovou verzi považuji za mnohem jednodušší číst. Můj mozek může podtržítka ignorovat mnohem snadněji, než dokáže detekovat hranice malých a velkých písmen v případě velblouda, zvláště tam, kde jsou hranice mezi glyfy, které vypadají podobně jako jiné glyfy opačného případu, nebo číslicemi (I/l, O/0, t/I atd.). Například tato logická proměnná ukládá hodnotu označující, zda bylo Igloo vytvořeno se správným plánovacím povolením (nepochybně běžný případ použití pro nás všechny):

isIllicitIgloo 

Považuji tuto verzi za hodně čitelnější:

is_illicit_igloo 

Možná ještě horší než těžko čitelný název symbolu je snadno čitelný název symbolu. Dobré názvy symbolů se samy dokumentují, což pro mě znamená, že byste měli být schopni je přečíst a pochopit jejich význam na první pohled. (Jsem si jistý, že si všichni čteme výtisky kódů v posteli pro potěšení, ale občas jsme také spěchali ve spěchu.) U názvů symbolů velbloudích písmen často narazím na to, že je snadné je špatně přečíst a získat špatný dojem sémantiky symbolu.

Komentáře

• Jeden problém s podtržítky: použitelnost. U většiny (evropských) klávesnic je při psaní podtržítka nutné podržet dolů klávesu SHIFT. Musíte to udělat také pro camelCase, ale můžu pohodlně podržet SHIFT s malíčkem a napsat libovolné písmeno – ale protože podtržítko je hned vedle klávesy SHIFT, stisknutí obou současně je poněkud trapné a přerušuje tok psaní.
• U prvního se mi camelCase ve skutečnosti zdálo čitelnější – i když ten druhý je zjevně odlišný.
• To opravdu záleží na tom, co ' znovu zvyklí. shledávám camelCases easierToRead a kromě toho jsou ' kratší než ekvivalentní podtržítka.
• Já nenávidět psaní podtržítka.
• Bod " použitelnost " je pro to irelevantní. Kód je obvykle napsán jednou jednou jednou osobou, ale ' s řekněme v řádu 1–10krát, což znamená nějaké úpravy a potenciální programování párů. Ale kód obvykle čte desítky / stovky / tisíce případů jeden nebo potenciálně mnoho lidí. Díky tomu je snadné čtení kódu o několik velikostí důležitější než snadné psaní kódu.

Myslím, že byste měli použít konvenci pojmenování přijatou vaší platformou. underscore_case bude v C # kódu vypadat divně, protože camelCase v Ruby =)

Komentáře

• Konzistence je klíč. Ať už souhlasíte s místní konvencí, nebo ne, díky konzistentnosti si usnadníte svůj čas (a všem ostatním ' s). (Pokud místní konvence není sama o sobě nekonzistentní.) Také čitelnost je většinou falešný argument: přečtěte si dostatek kódu, jakýkoli ' zjistíte, že existuje malý rozdíl, pokud se nerozhodnete, že je nečitelný.
• Plně souhlasím. Jen si myslím, že je lepší použít konvenci platformy místo vlastních, protože například noví lidé v týmu se s ní budou cítit pohodlněji.
• Ale běda těm z nás, kteří pracují na dvou platformách se dvěma konvencemi , kde někteří dávají přednost druhému a jiní dávají přednost druhému!
• Pokud má platforma 2 konvence, požádám ' d všechny členy týmu, aby hlasovali pro konvenci, která jim vyhovuje. =)

Upřímně řečeno, na tom opravdu nezáleží, pokud všichni členové týmu používají stejné schéma. Šance jsou jedno nebo druhé, je pro vás přirozenější, i když skutečnou důležitostí je dlouhodobá čitelnost kódu a poté je zásadní, aby všichni dodržovali stejná pravidla pojmenování.

Komentáře

• máte úplnou pravdu, ale ' se snažím zjistit, jaký názor na čarodějnice by bylo lepší použít (ať ' s pro celý tým), a proč … i když chápu, že někteří lidé mohou být zvyklí jen na nějakou konvenci, nebo jiní se chovají přirozeněji s tou druhou. = „answer“>

  Na základě odpovědi je odpověď Johna Isaackse:

  „upřímně řečeno, kód je čitelnější“ Názor nebo skutečnost?

  Rozhodl jsem se provést průzkum a našel jsem tento dokument . Co má na toto téma říct věda?

  1. Pouzdro velblouda má větší pravděpodobnost správnosti než podtržítka. (šance jsou o 51,5% vyšší)
  2. Průměrný případ velblouda trval o 0,42 sekundy déle , což je O 13,5% déle.
  3. Školení nemá statisticky významný dopad na to, jak styl ovlivňuje správnost.
  4. Osoby s více školení byly rychlejší o identifikátorech ve stylu velbloudů.
  5. Školení v jednom stylu, negativně ovlivní čas hledání pro další styly.

  V mém blogovém příspěvku na téma, které prohlížím vědecký článek a učinte následující závěr.

  Pouze pomalost velbloudího případu ( 2) je pro programování skutečně relevantní, přičemž ostatní body odmítá jako irelevantní kvůli moderním IDE a většině uživatelů camelCase ve studii. Diskuzi (spolu s anketou) najdete na blogovém příspěvku.

  Jsem zvědavý, jak by tento článek mohl změnit jejich názor. 🙂

  Komentáře

  • Všechny ostatní body samozřejmě odmítáte, protože dáváte přednost podtržítkům, a ostatní body vašemu případu nepomohou … '
  • @Charles: Ano a ne, IMHO dělám dobré argumenty, proč jsou odmítnutelné, a některé z nich jsou dokonce diskutovány samotnými příspěvky jako problematické. A následný článek zkoumá některé problémy tohoto článku a výsledky jsou podtržítka.

Zkopírujte nejchytřejší kluky

V případě programovacích jazyků zkopírujte styl vývojáře jazyka.

Například kóduji C přesně tak, jak je to v K & R.

Pak když se někdo pokusí spustit nudné kódování stylovou konverzaci, mohu jim říci „vychovávejte to s Dennisem Ritchem a dejte mi vědět, co říká.“

Komentáře

• Originál není vždy nejlepší. V knize evangelia K & R o C. existuje mnoho špatných postupů. Než to začne plamennou válku … přečtěte si některá doporučení MISRA.
• Nezapomeňte ', K & R bylo napsáno, pokud neexistují IDE GUI. Většina práce byla provedena na terminálech o rozměrech 80 x 25 znaků, takže prostor na obrazovce byl špičkový, takže if (...) { uložil řádek! V dnešní době je ' více prostoru na obrazovce – bylo by K & R jiné, kdyby bylo dnes napsáno s hi-res GUI IDE a více monitorů nastavení?
• Ano, ale když někdo řekne, že kóduje C jako K & R, dostanou rekvizity za to, že jsou old-school.
• @quickly_now , přiveďte to s Dennisem Ritchiem a dejte mi vědět, co říká!
• Přijímám mnoho formátování z MS: _internalToClassOnly, accessibleByGetter, PublicVariable.

Obecně mám raději camelCase. Je to však proto, že většinu své kariéry pracuji v jazycích a prostředích, kde průvodci stylem obvykle doporučují camelCase. (Java, ECMAScript, C ++). Jako osoba PHP pravděpodobně budete mít opačné preference.

To znamená, že když jdete nad rámec threeOrFourWords, nebo pokud použijete inicialismy jakoXmlForExample, přestane být tak čitelný.

Proto nám emacs dává režim brýlí.

Komentáře

• +1 za to, že mě přiměl objevit režim brýlí! Právě jsem to otestoval na souboru kódu, který používá camelCase, a všiml jsem si, jak to okamžitě začalo vypadat lépe (montáž se spoustou štítků v camelCase).
• Dobře, co je režim brýlí?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Toto je jedno z mála míst, kde vždy vyberu“ typovou schopnost „před čitelností. CamelCase je prostě snazší psát a být příjemnější k mým prstům vyhrává nad mírným ziskem čitelnosti pro mě.

samozřejmě za předpokladu, že projekt nevychází z existujícího základu kódu s jiným standardem.

Komentáře

• Nesouhlasím s tím ', kód napíšete pouze jednou, ale budete si ho muset přečíst několikrát

Je to zajímavá otázka, mnohokrát jsem nad tím přemýšlel. Myslím však, že neexistuje jednoznačná odpověď.

Podle „kulturních“ konvencí je to dobrá volba. „Kulturní“ v tomto případě znamená konvence nastavené v týmu / společnosti a v zásadě také nesou konvence jazyka / platformy. Pomáhá ostatním snadno číst / používat váš kód a nevyžaduje další úsilí a čas, aby se naučili rozumět vašemu kódu.

Někdy je zajímavé porušit přijaté notace. Jeden z mých malých projektů (v Pythonu) jsem použil underscored_names pro obslužné funkce / „chráněné“ metody a Java-style methodNames pro metody. Můj tým byl šťastný s tím 🙂

Závisí na programovacím jazyce.

Zvažuji použití případu v stejný člun, zda použít maďarskou notaci:

• Python: underscore_case, žádná maďarská notace
• C ++: camelCase, maďarská notace

Komentáře

• @Kevin Cantu: Název Javascript je ve skutečnosti spíše v PascalCase než camelCase …
• @Guffa: touch é!
• @Kevin Cantu: na JavaScriptu: XMLHttpRequest < – Nesnáším toto jméno vášeň.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: Maďarská notace se ve skutečnosti v C ++ téměř nikdy nepoužívá, protože C ++ již vaše typy kontroluje. ' Je to spíše historický artefakt než cokoli jiného.

Oba!

V CakePHP provádím velký vývoj a používám buď CamelCase nebo $underscored_vars, následujícím způsobem (i mimo projekty CakePHP):

1. názvy souborů – /lowercased_underscored.php Typické, ale stojí za zmínku.
2. tříd – class CamelCase extends ParentObject. Upozorňujeme, že při použití CamelCase není počáteční znak malými písmeny. Připadá mi camelCase vypadat opravdu divně.
3. proměnné – $are_variables_underscored === TRUE;
4. proměnné, které obsahují instance – $CamelCase = new CamelCase();
5. klíče pole – $collection["underscored_keys"];
6. konstanty – myslím každý může souhlasit s tím, že konstanty by měly být ALL_CAPS_AND_UNDERSCORED.
7. metody – $CamelCase->foo_method_underscored();
8. statické metody – CamelCase::just_like_regular_methods();

Komentáře

• s vámi musí souhlasit, přičemž první znak musí být nižší případ mě přivádí k šílenství! Nesnáším camelCase s vášní.
• V Javě, kde jsou jména obvykle velbloudaNázev tříd ve skutečnosti začíná velkým písmenem. Tím se odlišují od názvů metod.

Osobně preferuji underscore_case protože mi připadá čitelnější, ale souhlasím s ostatními respondenty, kteří poukazují na to, že mnohem důležitější je konzistence se stávající základnou kódů.

Mám však protiklad pro ty, kteří říkají „ řiďte se konvencemi vašeho jazyka a jeho knihoven „.

V minulosti jsme psali C kód pro Windows pomocí underscore_case a volali jsme PascalCase Funkce Win32:

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

Vizuální rozdíl mezi názvy našich funkcí a názvy funkcí společnosti Microsoft byl spíše pomoc než překážka, protože jasně ukázal, kdy se kód dostal do „systémové země“.

Kromě toho jsem byl schopen změnit pravidla zvýraznění syntaxe mého editoru tak, aby byla zobrazena v různých barvách, což při pokusu o porozumět neznámým částem kódu (nebo dokonce mým vlastním).

Opravdu se mi líbí Dylanovy jen-normální-čárky-jako-jsou-snadno-psát-a-snadno -to-read.

Líbí se

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

Ale myslím, že protože tento jazyk je docela temný, je to tak trochu mimo téma. .. 🙁

Komentáře

• Jsem také unavený stiskem shift pro psaní podtržítka.
• To obvykle není možné pro názvy proměnných, protože " – " obvykle znamená minus.

Na univerzitě mě naučili používat camelCase. Během posledních několika let jsem použil několik různých konvencí, ale dávám přednost camelCase před čímkoli jiným. Myslím, že si pamatuji, že jsem někde četl, že camelCase je ve skutečnosti nejjednodušší číst a rozumět.

Komentáře

• no ' s není easyer, protože jste někde četli, ' s easyer protože to bylo první, se kterým jste pracovali, a hlavně proto, že jste na to zvyklí, například mi ' m více vyhovuje underscore_case.
• jako v i ' četl jsem, že byla provedena studie, a zjistil jsem, že je to lepší ..

Někdy používám kombinaci: module_FunctionName. Všechny (nestatické) funkce v mých modulech začínají zkratkou modulu.

Například funkce pro odesílání obsahu vyrovnávací paměti na sběrnici I2C:

i2c_BufferSend() 

Alternativa i2c_buffer_send nevykazuje dostatečně velké oddělení mezi předponou a názvem funkce. i2cBufferSend se mísí v předpona příliš velká (v tomto modulu je celá řada funkcí I2C).

i2c_Buffer_send však mohla být alternativou.

Moje odpověď je, že se přizpůsobíte tomu, co nejlépe vyhovuje vašemu projektu (váš jazyk, vaše SW architektura, …), a chtěl jsem poukázat na to, že míchání těchto stylů může být užitečné.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Komentáře

• +1 pro poslední 2 řádky, nedoporučuji však kombinovat konvence pojmenování, měli byste se držet jednoho neboother.
• Dokud je konvence dobře definována (prefix + podtržítko + PascalCase) …
• Rád používám podtržítka k oddělení částí názvu, které mají sémanticky disjunktní účely, zejména pokud může být shodnost na jedné polovině významná. Například rutiny Motor1_Start(), Motor2_Start(), Motor1_Stop() a Motor2_Stop() mají vztah, který by bez podtržítka mohl být méně jasný.

Osobně , Dávám přednost camelCase, ale u některých typů písma si myslím, že podtržítka jsou čitelnější.

Navrhuji, že pokud potřebujete rozlišovat sady proměnných pomocí předpon, měli byste použít jazyk, který vám umožní vytvářet jmenné prostory nebo objekty nebo něco, co tyto informace uchovává.

myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D 

Podobně, pokud potřebujete rozlišovat typy, proč nepoužívat jazyk, který jim to umožňuje?

var intThingy = 7; // :( int thingy = 7; // :) 

Jakmile to máte rovné a nepoužíváte jen jméno jako metadata, nebudete mít dost dlouhých jmen, záleží na tom, zda dáváte přednost tomuto extra stisknutí kláves nebo ne.

Komentáře

• Jedním z důvodů pro použití camelCase nebo underscore_case je to, že nemám ' t je třeba najít definici objektů, aby bylo možné rozeznat, o co jde.

Nejprve souhlasím s dafmetal . Je nanejvýš důležité, abyste nemíchali různé styly programování. Dělat to v jednom a stejném souboru je to nejhorší, co můžete udělat IMHO. Napříč různými soubory je to rušivé, ale ne fatální.

Další věcí, kterou musíte udělat, je pojmenování pravidel, která jsou populární pro jazyk, ve kterém píšete. Můj C ++ kód pro instace, bude vypadat pro Python zjevně jinak (PEP8 je zde pěkný průvodce)

Můžete také použít různé konvence pojmenování pro označení různých věcí, stejně jako pravděpodobně používáte UPPER_CASE pro konstanty (to platí pouze pro určité samozrejme jazyky), můžete použít this_style pro názvy místních proměnných, zatímco pro proměnné instance / členské proměnné používáte camelCase. To nemusí být nutné, pokud máte věci jako self nebo this.

Aktualizovat

Vezměme si případ, kdy máte platformu Foo čarodějnice nedoporučuje žádné konvence pojmenování a je na výběr vedoucího týmu. Jste tím vedoucím týmu, proč byste si vybrali camelCase nebo proč underscore_case.

Ve skutečnosti neexistují žádné výhody pro jednoho. Tato záležitost je velmi subjektivní a po dohodě to nezmění. O tyto malé věci vždy existují tyto náboženské války. Ale jakmile se nastavíte buď, diskuse se zdají být naprosto zbytečné.

Citovat Alexe Martelliho ve velmi podobné věci:

Jistě, v Ruby jsem unavený z psaní hloupého „konce“ na konci každého bloku (spíše než jen odvíjení) – ale pak se musím vyhnout psaní stejně hloupého „:“, který Python vyžaduje na začátku každého bloku, aby bylo „téměř umyté :-). Jiné rozdíly v syntaxi, jako je„ @foo “oproti„ self.foo “, nebo vyšší význam případu v Ruby vs Python jsou pro mě opravdu téměř stejně irelevantní.

Jiní bezpochyby zakládají svou volbu programovacích jazyků právě na takových problémech a vytvářejí nejžhavější debaty – ale pro mě je to jen příklad jednoho z Parkinsonových zákonů v akci ( částka debaty o problému je nepřímo úměrná skutečnému významu problému ).

Zdroj

Pokud jste vedoucí týmu, stačí jít s jedním. Jelikož jeden nemá žádné výhody oproti druhému, můžete hodit kostkou nebo vybrat to, co se vám líbí víc.

Před několika lety jsem četl, že programátoři, kteří nehovoří anglicky jako prvním jazykem, mají tendenci najít podtržítko snadněji pochopit, že velbloudí případ – ale nemohu najít referenci a já netuším, zda je to pravda.

Pro programovací jazyky jsem používal, jako Java, Python, C ++, přijal jsem jasný formát:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

To mi umožňuje okamžitě rozeznat, s čím mám co do činění. Zjistil jsem, že je užitečné si to udržovat sám pro sebe a mělo by být snadné ho sledovat pro někoho jiného, kdo čte kód. Myslím, že protože ostatní zmínili konzistenci, je nejdůležitější. Takže najdu svůj formát aby byl dostatečně jednoduchý na údržbu a přitom poskytoval jasné rozdíly mezi typy jmen. Dokázal jsem si představit interface_Names_Are_Like_This a Abstract_Classes_Are_Like_This jako možná rozšíření, ale zdá se, že je komplikovanější je sledovat a možná ne tak užitečné rozlišení.

Také jsem zjistil, že je užitečné být přísný a pojmenovat věci v PascalCase, jako je HTML analyzátor jako HtmlParser místo HTMLParser nebo HTMLparser. Protože věřím, že je snazší si pamatovat přísné pravidlo a udržuje hranice slov jasnější (bohužel vyžaduje chybně napsané věci, jako je HTML nebo SQL). Podobně s camelCase, htmlParserMethod místo HTMLParserMethod nebo HTMLparserMethod.

UPDATE :

Od té doby jsem našel použití při rozšiřování těchto pravidel o soukromé proměnné.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

V Javě to znamená, že soukromá pole jsou podle definice v jiném oboru názvů než místní proměnné, což znamená, že můžete

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Odpověď

Odpověď