it-swarm-eu.dev

Konvence pojmenování: camelCase versus podtržítko? co si o tom myslíš?

Používám funkci underscore_case již asi 2 roky a nedávno jsem přešel na camelCase kvůli nové úloze (ten poslední používám asi 2 měsíce a stále si myslím, že je undererscore_case vhodnější pro velké projekty, kde je spousta programátorů, hlavně proto, že je kód lépe čitelný).

Nyní každý v práci používá camelCase, protože (tak říkají) kód vypadá elegantněji.

Jaké jsou vaše myšlenky na camelCase nebo podtržítko

p.s. promiňte prosím moji špatnou angličtinu

pravit

Někteří aktualizujte nejprve:

  • použitá platforma je PHP (ale neočekávám přísné PHP odpovědi související s platformou), kdokoli se může podělit o své myšlenky, na které by bylo nejlepší použít, to je proč jsem sem přišel na prvním místě)

  • Používám camelCase stejně jako kdokoli jiný v týmu (stejně jako většina z vás doporučuje)

  • používáme Zend Framework, který také doporučuje camelCase

Několik příkladů (souvisejících s PHP):

  • Framework Codeigniter doporučuje podtržítko a kód je čitelnější.

  • ZF doporučuje camelCase a nejsem jediný, kdo si myslí, že kód ZF je o dost těžší sledovat.

Takže moje otázka bude přeformulována:

Vezměme si případ, kdy máte platformu Foo, která nedoporučuje žádné pojmenovací konvence a je na výběru vedoucího týmu. Jste týmový vůdce, proč byste si vybrali camelCase nebo proč podtržítko?

p.s. děkuji všem za odpověď na výzvu

70
poelinca

Souhlasím, že to záleží na jazyce, který do určité míry používáte; kód má sklon vypadat čistěji, když se vaše názvy symbolů řídí stejným formátovacím režimem jako vestavěné knihovny a knihovny zásob.

Ale tam, kde je na výběr, upřednostňuji podtržítka před velbloudovým pouzdrem, a to z jednoho jednoduchého důvodu: tento styl je pro mě čitelnější. Zde je příklad: který je pro vás čitelnější? Tento:

aRatherLongSymbolName

nebo toto:

a_rather_long_symbol_name

Verze podtržítka je pro mě mnohem snáze čitelná. Můj mozek může ignorovat podtržítka mnohem snadněji, než dokáže detekovat hranice malých a velkých písmen v případě velblouda, zejména pokud jsou hranice mezi glyfy, které vypadají podobně jako jiné glyfy opačného případu, nebo číslice (I/l, O/0, t/I, atd). Například tato booleovská proměnná ukládá hodnotu označující, zda byl Igloo postaven se správným plánovacím povolením (nepochybně společný případ použití pro nás všechny):

isIllicitIgloo

Tuto verzi považuji za lot snadněji čitelnou:

is_illicit_igloo

Snad ještě horší než těžko čitelný název symbolu je snadno pochopitelný název symbolu. Dobré názvy symbolů jsou samokumentující, 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 všichni čteme kódové výtisky v posteli pro potěšení, ale občas se také spěcháme.) Často se jmény symbolů velbloudů často objevuji, že je snadné je špatně přečíst a získat špatný dojem sémantika symbolu.

84
Simon Whitaker

Myslím, že byste měli používat konvenci pro pojmenování přijatá vaší platformou. podtržítko bude vypadat divně v kódu C #, jako camelCase v Ruby =)

97
Alexey Anufriyev

Upřímně řečeno, nezáleží na tom, dokud všichni v týmu používají stejné schéma. Pravděpodobnost, že jeden nebo druhý je pro vás přirozenější, je skutečná důležitost čitelnosti kódu v dlouhodobém horizontu a poté je důležité, aby všichni dodržovali stejná pravidla pojmenovávání.

20
dafmetal

Na základě odpovědi odpověď John Isaacks:

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

Rozhodl jsem se udělat nějaký výzkum a našel tento článek . Co má věda na toto téma?

  1. Velbloudí plášť má větší pravděpodobnost správnosti než podtržítka. (kurzy jsou o 51,5% vyšší)
  2. Průměrná doba velblouda trvala o 0,42 sekundy déle , což je o 13,5% déle.
  3. Trénink nemá statisticky významný dopad na to, jak styl ovlivňuje správnost.
  4. Ti s více tréninkem byli rychleji na identifikátorech ve stylu velbloudů.
  5. Trénink v jednom stylu negativně ovlivňuje čas hledání pro jiné styly.

V můj blogový příspěvek na toto téma recenzuji vědeckou práci a učiním následující závěr.

Pouze pomalost velbloudu (2) je pro programování skutečně důležitá, ostatní body jsou kvůli moderní IDE a většina uživatelů camelCase ve studii. Diskuse (spolu s anketou) najdete na blogu.

Jsem zvědavý, jak tento článek může změnit názor lidí. :)

20
Steven Jeuris

Zkopírujte nejchytřejší kluky

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

Například jsem kód C přesně tak, jak se to dělá v K&R.

Když se pak někdo pokusí začít nudnou konverzaci ve stylu kódování, mohu jim říci, „aby to vzal s Dennisem Ritchem a dejte mi vědět, co říká.“

11
Mark Harrison

Obecně dávám přednost 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 běžně doporučují camelCase. (Java, ECMAScript, C++). Vy, kdo jste PHP osoba), budete pravděpodobně mít opačné preference.

To znamená, že když překročíte hranici tří nebo více, nebo pokud použijete inicializační soubory jako je XmlForExample, přestane být tak čitelný.

Proto nám emacs dává brýle.

10
Paul Butcher

camelCase

Toto je jedno z mála míst, které si vždy vyberu „typovou schopnost“ před čitelností. CamelCase je prostě snazší psát a být hezčí k mým prstům vyhraje přes mírný zisk čitelnosti pro mě.

za předpokladu, že projekt nestaví na existující kódové základně s jiným standardem.

8
AShelly

Je to zajímavá otázka, o které jsem mnohokrát přemýšlel. Ale myslím, že neexistuje jednoznačná odpověď.

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

Někdy je zajímavé přerušit přijímané notace. Jeden z mých malých projektů (na Pythonu) jsem použil underscored_names pro obslužné funkce/"chráněné" metody a Java styl methodNames pro metody. Můj tým s tím byl spokojený :)

7
duros

Závisí na programovacím jazyce.

Uvažuji o použití případu na stejné lodi, zda použít maďarský zápis:

  • Python: podtržítko, žádná maďarská notace
  • C++: camelCase, maďarská notace
6
Lionel

Oba!

V CakePHP pracuji hodně 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řídy - class CamelCase extends ParentObject. Všimněte si, že při použití CamelCase není počáteční znak malými písmeny. Zjistil jsem camelCase vypadat opravdu podivně.
  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, že 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();
6
Stephen

Já osobně dávám přednost underscore_case protože to považuji za čitelnější, ale souhlasím s ostatními respondenty, kteří zdůrazňují, že soulad s existující kodebázou je mnohem důležitější.

Mám však protějšek pro ty, kteří říkají „dodržujte konvenci vašeho jazyka a jeho knihoven“.

V minulosti jsme psali C kód na Windows pomocí underscore_case a nazvané PascalCase Funkce Win32:

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

Vizuální rozlišení mezi našimi funkčními jmény a funkčními názvy Microsoftu bylo spíše pomocné než překážky, jak jasně ukázalo, když se kód dostal do „systémové země“.

Kromě toho jsem mohl změnit pravidla zvýraznění syntaxe svého editora tak, aby se zobrazovala v různých barvách, což dávalo další vizuální stopy, když se snažím porozumět neznámým částem kódu (nebo dokonce mým vlastním).

5
Paul Stephenson

Moc se mi líbí jen normální, Dylanovy pomlčky, protože jsou snadno čitelné a snadno čitelné.

Jako

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

Ale myslím, že tento jazyk je docela nejasný, je to trochu mimo téma ... :(

5
Kosta

Naučil jsem se používat camelCase na univerzitě. Během posledních několika let jsem použil několik různých konvencí, ale raději camelCase před čímkoli jiným. Myslím, že si vzpomínám, že jsem si někde přečetl, že camelCase je ve skutečnosti nejjednodušší číst a porozumět.

4
Ross

Osobně dávám přednost camelCase, ale u některých písem si myslím, že podtržítka jsou snáze čitelná.

Navrhl bych, že pokud potřebujete použít předpony k rozlišení sad proměnných, měli byste použít jazyk, který vám umožní vytvořit jmenné prostory nebo objekty nebo něco, co tyto informace uchovává.

myName   = 7
bobsName = 8   // :(

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

Stejně tak, pokud potřebujete rozlišit typy, proč nepoužívat jazyk, který jim umožňuje?

var intThingy = 7; // :(

int thingy = 7;    // :)

Jakmile to máte rovné a název nepoužíváte pouze jako metadata, nebudete mít dost dlouhých jmen, na kterých by záleželo, ať už dáváte přednost tomuto extra stisknutí klávesy.

4
Kevin Cantu

Jak již uvedla většina lidí - použijte existující standard. Pokud se jedná o nový projekt, použijte standard pro jazyk a rámce, které budete používat.

A nenechte se zmást, nejedná se o čitelnost (což je subjektivní), je to o důslednosti a profesionálnosti. Každý, kdo pracoval v kódové základně s četnými „standardy“, bude tomu rozumět.

4
Colin Goudie

Někdy používám mix: 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 nezobrazuje dostatečně velké oddělení mezi předponou a názvem funkce. i2cBufferSend se mísí v předponě příliš mnoho (v tomto modulu je docela dost funkcí I2C).

i2c_Buffer_send ale mohla být alternativou.

Moje odpověď je, že se přizpůsobíte tomu, co pro váš projekt nejlépe funguje (váš jazyk, architektura SW, ...) a chtěl jsem zdůraznit, že smí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.

4
Gauthier

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

  • ClassNamesArePascalCase
  • methodNamesAreCamalCase
  • variable_names_are_underscore
  • CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

To mi umožňuje okamžitě rozeznat, s čím se zabývám. Zjistil jsem, že je užitečné udržovat se pro sebe, a mělo by být snadné sledovat někoho, kdo čte kód. Myslím si, že ostatní zmínili konzistenci. Zjistil jsem tedy, že můj formát je dostatečně jednoduchý na údržbu a zároveň jasně rozlišuje mezi typy jmen. Dokážu si představit interface_Names_Are_Like_This a Abstract_Classes_Are_Like_This jako možná rozšíření, ale zdá se, že je obtížnější je následovat a možná ne tak užitečným rozlišením.

Také jsem zjistil, že je užitečné být přísný a pojmenovávat věci v PascalCase, jako je HTML parser, jako HtmlParser místo HTMLParser nebo HTMLparser. Protože věřím, že je snazší zapamatovat si přísné pravidlo a udržet jasnější hranice Wordu (bohužel to vyžaduje překlepy, jako HTML nebo SQL). Podobně jako u camelCase, htmlParserMethod místo HTMLParserMethod nebo HTMLparserMethod.

[~ # ~] aktualizace [~ # ~] :

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 přeskočit this. na soukromých polích. Jiné formáty, které jsem viděl s předponou „m“, ale tyto formáty používají také názvy proměnných camelCase. To mi také umožňuje rozlišovat mezi poli, ke kterým by měla třída přistupovat pouze interně (a aby bylo jasné super jasné, když se to děje mimo třídu object._field_x vyčnívá).

2
Dandre Allison

Nejprve souhlasím s dafmetalem. Je nanejvýš důležité, abyste nemíchali různé programovací styly. Dělat to v jednom a stejném souboru je nejhorší, co můžete udělat IMHO. V různých souborech 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, do kterého píšete. Můj C++ kód pro instinkci, bude vypadat jinak než něco pro Python samozřejmě (PEP8 je pěkný průvodce zde)

Můžete také použít různé konvence pojmenování pro odkazování na různé věci, protože pravděpodobně používáte UPPER_CASE pro konstanty (samozřejmě to platí pouze pro určité jazyky), můžete použít tento_style pro názvy lokálních proměnných, zatímco pro camelCase například/člena proměnné. To nemusí být nutné, pokud máte věci jako self nebo this.

Aktualizace

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

Neexistují žádné výhody pro jednoho oproti druhému opravdu. Tato záležitost je velmi subjektivní a jakmile bude dohodnuta, nebude to mít žádný význam. O těchto malých věcech vždy existují tyto náboženské války. Jakmile se ale přizpůsobíte, diskuse se zdají být naprosto zbytečné.

Citovat Alexa Martelliho ve velmi podobné záležitosti:

Jistě, v Ruby mě unavuje psaní hloupého „konce“ na konci každého bloku (spíše než pouhé odsunutí) - ale pak se vyhnu, abych nenapsal stejně hloupé ':' což Python vyžaduje na start každého bloku, takže je to téměř mytí :-). Jiné rozdíly v syntaxi, jako je „@foo“ ve srovnání s „self.foo“, nebo vyšší význam případu v Ruby vs. Python) jsou pro mě ve skutečnosti stejně irelevantní.

Jiní nepochybně zakládají svůj výběr programovacích jazyků pouze na takových otázkách a vytvářejí nejžhavější debaty - ale pro mě je to jen příklad jedné z Parkinsonových zákonů v akci ( částka na debatu) v záležitosti je nepřímo úměrná skutečné důležitosti problému ).

Zdroj

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

2
phant0m

Před několika lety jsem četl, že programátoři, kteří nemluví anglicky jako první jazyk, mají tendenci shledávat případ podtržítka snazší pochopit ten případ velblouda - ale nemůžu najít odkaz a nemám tušení, zda je to pravda.

2
Ed Harper

Kdyby to bylo na mě, nevynucoval bych ani nenaznačoval použití nějakého zvláštního stylu, protože jako programátoři bychom mohli být schopni přečíst symbol IfItIsInCamelCase nebo in_underscore_space nebo dokonce in_SomeOtherStyle a pochopit, co to znamená. Potřeba strávit malé množství času analýzou symbolu není velkou režií ve velkém schématu věcí.

Hlavním argumentem pro konvenci je nyní to, že víte předem, jaký je formát názvu funkce/proměnné a nemusíte ji vyhledávat - je to LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Nyní bych proti tomuto argumentu čelil slovy: „Získejte IDE, které podporuje automatické dokončení inteligentního stylu!“ (Ne vždy však možné).

Nakonec však nezáleží na tom, jaký styl používáte, protože překladač/tlumočník to opravdu nezajímá. Důležité je, že název je užitečný:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Tři různé styly, ale přesně víte, co každý dělá.

1
Skizz

Mám sklon upřednostňovat camelCase z hloupého důvodu, že většinu svého vývoje dělám v Eclipse (pro Javu PHP a JavaScript)) a když Ctrl+ nebo Ctrl+ slovy, ve skutečnosti se zastaví na hranici camelCase.

I.e .: myIntVariable by Eclipse považoval za 3 slova, když Ctrl+← →skrz to.

Vím, že je to podivný vtip, ale zjistil jsem, že upřednostňuji možnost upravovat prostřední slova v názvu camelCase.

0
Bassam

Může to vypadat hloupě, ale nemám rád podtržítka, protože podtržítko je tenké a skrývá se ve víceřádkovém textu a chybí mi to. Také v některých (mnoha) textových editorech a/nebo dev prostředích, když dvakrát kliknete na název tokenu, abyste jej zvýraznili tak, že jej zkopírujete nebo přetáhnete, systém nezvýrazní celý token, zvýrazní pouze jednu část tokenu, mezi sousedními podtržítky. To mě pohání ořechy.

0
Charles Bretana