Elnevezési konvenciók: camelCase kontra aláhúzás_eset? mi a véleményed róla? [zárt]

Személyesen , Inkább a camelCase-t részesítem előnyben, de egyes betűtípusokban szerintem az aláhúzások könnyebben olvashatók.

Javaslom, hogy ha előtagokkal kell megadni a változókészleteket, akkor használjon olyan nyelvet, amely lehetővé teszi névterek készítését vagy tárgyak, vagy valami, ami ezeket az információkat tárolja.

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

Hasonlóképpen, ha meg kell különböztetni a típusokat, miért ne használhatna olyan nyelvet, amely lehetővé teszi számukra?

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

Ha ezt megadta, és nem csak meta-adatként használja a nevet, akkor nem lesz elég hosszú neve ahhoz, hogy nagyon számít, hogy inkább az extra billentyűleütést választja-e vagy sem.

Megjegyzések

• A camelCase vagy az aláhúzás_betű használatának egyik oka az, hogy nem ' t meg kell találni az objektumdefiníciót, hogy felismerje, mi az.

Eleinte egyetértek a dafmetal-val . A legfontosabb, hogy ne keverje össze a különböző programozási stílusokat. Ha ezt egy és ugyanazon fájlban végzi, akkor a legrosszabb, amit IMHO-nak tehet. Különböző fájlokban ez zavaró, de nem végzetes.

A következő dolog, amit meg kell tennie, hogy olyan szabályokat nevezzen meg, amelyek népszerűek annak a nyelvnek, amellyel Ön ír. Az én C ++ kódom az instnace számára másnak tűnik, mint valami a Python esetében (a PEP8 itt egy jó útmutató)

Különböző elnevezési konvenciókat is használhat különböző dolgokra való hivatkozáshoz, amennyire valószínűleg az UPPER_CASE-t használja konstansokra (ez csak bizonyos Természetesen a nyelveken), ezt az_style-t használhatjuk a helyi változók nevéhez, míg a camelCase-t például a / member változókhoz. Erre valószínűleg nem lesz szükség, ha például self vagy this van.

Frissítés

Vegyünk egy olyan esetet, amikor van egy platformod, a Foo boszorkány nem ajánl semmilyen elnevezési konvenciót, és a csapat vezetője választhat egyet. Te vagy a csapat vezetője, miért választanád a camelCase-t, vagy miért az aláhúzás_eset.

Nincsenek előnyei egyiknek a másikkal szemben. Ez az ügy nagyon szubjektív, és miután megállapodtak, nem fog változtatni. Mindig vannak ezek a vallásos háborúk ezekről a kis dolgokról. De ha már bármelyikhez igazodsz, a beszélgetések teljesen feleslegesnek tűnnek.

Alex Martellit idézve egy nagyon hasonló kérdésről:

Bizony, elfáradok a Ruby-ban, hogy az egyes blokkok végére begépelem az ostoba “véget” (nem csak behúzás nélkül) -, de aztán elkerülöm az ugyanolyan ostoba “:” A Python minden blokk kezdeténél megköveteli, hogy “majdnem lemosódjon :-). Egyéb szintaxis különbségek, például a” @foo “és az” self.foo “, vagy az eset nagyobb jelentősége a A Ruby vs Python valójában éppoly lényegtelenek számomra.

Mások kétségkívül csak ilyen kérdésekre alapozzák a programozási nyelv választását, és a legforróbb vitákat generálják – de számomra ez csak egy példa a Parkinson egyik törvényének működésére ( a kérdésről folytatott vita összege fordítottan arányos a kérdés aktuális fontosságával ).

Forrás

Ha Ön a csapat vezetője, akkor csak egyet kell választania. Mivel az egyiknek nincs előnye a másikkal szemben, egyszerűen dobhat kocka, vagy kiválaszthatja azt, ami jobban tetszik.

Több évvel ezelőtt olvastam, hogy azok a programozók, akik nem beszélnek angolul első nyelvként, hajlamosak az aláhúzást könnyebben megérteni, mint a teve esetét, de nem találom a hivatkozást, és fogalmam sincs, hogy igaz-e.

Azoknál a programozási nyelveknél, amelyeket használtam, mint a Java, Python, C ++, világos formátumot fogadtam el:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Ez lehetővé teszi számomra, hogy azonnal felismeri, hogy mivel foglalkozom. Megállapítottam, hogy hasznos fenntartani magamnak, és könnyen követhetőnek kell lennie másoknak, akik elolvassák a kódot. Úgy gondolom, hogy ahogy mások említették, a következetesség a legfontosabb. Tehát megtalálom a formátumomat elég egyszerű a karbantartáshoz, miközben egyértelmű különbséget tesz a névtípusok között. Elképzelhetném az interface_Names_Are_Like_This és az Abstract_Classes_Are_Like_This lehetséges kiterjesztéseket, de úgy tűnik, hogy bonyolultabb követni őket, és talán nem olyan hasznos megkülönböztetni őket.

Hasznosnak találtam azt is, ha szigorú vagyok és a PascalCase-ben olyan dolgokat nevezek meg, mint egy HTML elemző, mint HTMLParser, vagy HtmlParser. HTMLparser. Mivel úgy gondolom, hogy könnyebb megjegyezni a szigorú szabályt, és tisztábban tartja a szóhatárokat (sajnos olyan hibás írásokat igényel, mint a HTML vagy az SQL). Hasonlóan a camelCase-hez, a HTMLParserMethod vagy HTMLparserMethod helyett a htmlParserMethod.

FRISSÍTÉS :

Azóta megtaláltam a felhasználást a szabályok kibővítésére magánváltozókkal.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

A Java-ban ez azt jelenti, hogy a privát mezők definíció szerint egy másik névtérben vannak, mint a helyi változók, ami azt jelenti, hogy “private0” mezők. Más formátumok “m” előtagot láttam, de ezek a formátumok a camelCase-t is használják a változók nevéhez. Ez lehetővé teszi számomra, hogy különbséget tegyek olyan mezők között, amelyekhez csak belsőleg kell hozzáférni. osztály által (és szuper tisztává téve, ha az osztályon kívül történik object._field_x kiemelkedik).

Ha rajtam múlna, nem kényszerítenék rá és nem is utalnék rá bármely adott stílus használata, mert programozóként képesek lennénk elolvasni egy szimbólumot IfItIsInCamelCase vagy in_underscore_space vagy akár in_SomeOtherStyle és megérteni, mit jelent. Ha a szimbólum elemzésével csekély időt kell tölteni, az nem nagy rezsi a nagy rendszerben a dolgokról.

Most azt gondolom, hogy a konvenció fő érve az, hogy előre tudod, mi a függvény / változó név formátuma, és nem kell utánanézned – ez LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Most ellenkeznék ezzel az érveléssel: “Szerezzen egy IDE-t, amely támogatja az intelligens stílusú automatikus kiegészítést!” (bár nem mindig lehetséges).

A végén azonban nem mindegy, hogy milyen stílust használsz, mert a fordító / tolmács nem igazán érdekli. Ami fontos, hogy a név hasznos legyen:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Három különböző stílus, de pontosan tudja, hogy mindegyik mit csinál.

Megjegyzések

• Könyörögni szoktam, fontos a forrás megjelenése. Lásd: " A pragmatikus programozó " ' s törött Windows-elmélet. A változó elnevezési szokások rontják a megjelenést. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Bár egyetértek a ' törött ablak ' ötlet, nem hiszem, hogy ' nem gondolom, hogy a szimbólumok nagybetűsítése ' törött ablak '. A véletlenszerűen lefektetett kód bizonyára az, és a jelenlegi projektemnek bizonyára sok olyanja van, amelyet megpróbálok rendet tenni, amikor csak tudok.
• Egyetértek. Mindhármat egyformán jól tudom olvasni. Nem számít '. Csak azt használom, amit a fájl használ, akkor bármit javasol a nyelv (python), majd bármi, amit úgy érzem, a projekt lesz a legjobban kiszolgálva. (Korábban gwbasic-ban programoztam, és mindez nagybetűs volt – a régi szép időkben!)

Butaságnak tűnhet, de nem tetszik az aláhúzás, mert az aláhúzás vékony, több soros szövegben rejtőzik, és hiányzik belőlem. Ezenkívül néhány (sok) szövegszerkesztőben és / vagy fejlesztői környezetben, amikor duplán kattintasz egy token nevet annak kiemeléséhez, hogy másolja, vagy áthúzza, a rendszer nem fogja kiemelni a teljes tokent, csak a token egy részét emeli ki a szomszédos aláhúzások között. Ez engem vezet.

Én inkább a camelCase-t részesítem előnyben annak az ostoba okból, hogy fejlesztésem nagy részét Eclipse-ben végzem (Java, PHP és JavaScript esetén), és Ctrl + ← vagy Ctrl + → szavakkal, valójában a camelCase határokon áll meg.

Vagyis: myIntVariable az Eclipse 3 szóként kezelné, amikor Ct rl + ←   → ” keresztül.

Tudom, hogy ez furcsa furcsaság, de azt tapasztalom, hogy jobban szeretem szerkeszteni a camelCase név középső szavát.