Namngivningskonventioner: camelCase kontra understrykning_case? vad är dina tankar om det? [stängd]

Jag håller med om att det beror på språket du använder till viss del; koden tenderar att se snyggare ut när dina symbolnamn följer samma formatering regim som språket ”inbyggda och lagerbibliotek.

Men där det finns ett val, föredrar jag understrykning framför kamfodral, av en enkel anledning: Jag tycker att den stilen är lättare att läsa. Här” s ett exempel: vad tycker du är mer läsbart? Detta:

aRatherLongSymbolName 

eller detta:

a_rather_long_symbol_name 

Jag tycker att understrykningsversionen är mycket lättare att läsa. Min hjärna kan ignorera understrykningarna mycket lättare än att det kan upptäcka små / stora bokstäver i kamfallen, särskilt där gränserna ligger mellan tecken som liknar andra tecken i motsatt fall eller siffror (I/l, O/0, t/I, etc). Till exempel lagrar den här booleska variabeln ett värde som anger om en Igloo har byggts med rätt planeringstillstånd (utan tvekan ett vanligt användningsfall för oss alla):

isIllicitIgloo 

Jag tycker att den här versionen är mycket lättare att läsa:

is_illicit_igloo 

Kanske ännu värre än ett svårläst symbolnamn är ett lättläst symbolnamn. Bra symbolnamn är självdokumenterande, vilket för mig betyder att du ska kunna läsa dem och förstå deras mening med en överblick. (Jag är säker på att vi alla läser kodutskrifter i sängen för nöjes skull, men ibland grokar vi också i bråttom.) Jag tycker ofta att det med kamelhöljesymbolnamn är lätt att läsa dem fel och få fel intryck. av en symbol ”semantik.

Kommentarer

• Ett problem med understrykning: användbarhet. För de flesta (europeiska) tangentbord måste man skriva understreckstecknet. ner SHIFT-tangenten. Du måste också göra det för camelCase, men jag kan bekvämt hålla SHIFT intryckt med pinky och skriva vilken bokstav som helst – men eftersom understrykningsknappen är precis bredvid SHIFT-tangenten, är att trycka på båda samtidigt ganska besvärligt och avbryter skrivflödet.
• För det första tyckte jag att camelCase var lättare att läsa – även om det senare är uppenbart annorlunda.
• Detta beror verkligen på vad du ' är vana vid. Jag tycker att camelCases är lättare att läsa, och dessutom är de ' kortare än motsvarande understrykningsnamn.
• Jag hatar att skriva understrykningar.
• " användbarhet " är irrelevant för detta. Koden skrivs vanligtvis bara en gång av en person, men låt ' säga i storleksordningen 1-10 gånger och redogöra för viss redigering och potentiell parprogrammering. Men kod läses vanligtvis dussin / hundratals / tusentals gånger av en eller potentiellt många människor. Att göra kod lätt att läsa är därför flera storleksordningar viktigare än att ha kod lätt att skriva.

Jag tycker att du borde använda namngivningskonventionen som antagits av din plattform. understryksfält kommer att se konstigt ut i C # -kod, som camelCase i Ruby =)

Kommentarer

• Konsistens är en nyckel. Oavsett om du håller med om den lokala konventionen eller inte kommer du att göra din egen tid enklare (och alla andra ' s) genom att vara konsekventa. (Om inte den lokala konventionen i sig är inkonsekvens.) Dessutom är läsbarheten mestadels ett falskt argument: läs tillräckligt med kod som du ' upptäcker att det är liten skillnad om du inte bestämmer att den är oläslig.
• Håller helt med. Jag tycker bara att det är bättre att använda plattformskonvention istället för anpassade, för till exempel kommer nya killar i team att känna sig mer bekväma med det.
• Men ve dem som arbetar på två plattformar med två konventioner , där vissa föredrar och andra föredrar den andra!
• Om plattformen har två konventioner, ber jag ' alla lagmedlemmar att rösta på en konvention som de är bekväma med =)

Ärligt talat spelar det ingen roll så länge alla i laget använder Chansen är att den ena eller den andra är mer naturlig för dig, även om den verkliga vikten är kodens läsbarhet på lång sikt och då är det viktigt att alla följer samma namnregler.

Kommentarer

• du har rätt, men jag ' jag försöker ta reda på människors åsikt om häxan skulle vara bättre att använda (låt ' säger för hela laget) och varför … medan jag förstår att vissa människor bara kan vara vana vid någon konvention eller andra känner sig mer naturliga med den andra.

I allmänhet föredrar jag camelCase. Det beror dock på att jag under det mesta av min karriär har arbetat i språk och miljöer där stilguiderna normalt rekommenderar camelCase. (Java, ECMAScript, C ++). Du, som PHP-person, har sannolikt motsatt preferens.

Som sagt, när du går längre än treOrFourWords, eller om du använder initialismer somXmlForExample, slutar det vara så läsbart.

Det är därför emacs ger oss glasögonläge.

Kommentarer

• +1 för att få mig att upptäcka glasläge! Jag testade det bara på en kodfil som använder camelCase och märkte hur det omedelbart började se bättre ut (montering med massor av etiketter i camelCase).
• Okej, vad är glasögonläge?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Detta är en av få ställen jag alltid väljer” typ-förmåga ”framför läsbarhet. CamelCase är bara lättare att skriva, och att vara trevligare för mina fingrar vinner ut över en liten läsbarhetsökning för mig.

förutsätter naturligtvis att projektet inte bygger på en befintlig kodbas med en annan standard.

Kommentarer

• Jag håller inte ' Jag håller inte med det, du skriver bara en gång, men du måste läsa den flera gånger efteråt

Det är en intressant fråga, jag har tänkt på det många gånger. Men det finns inget definitivt svar, tror jag.

Enligt de ”kulturella” konventionerna är det ett bra val. ”Kulturell” betyder i det här fallet konventioner som sätts upp i teamet / företaget och de bär i princip även språk / plattformskonventionerna. Det hjälper andra att läsa / använda din kod enkelt och kräver inte ytterligare ansträngningar och tid för att komma in på sättet att förstå din kod.

Ibland är det intressant att bryta accepterade noteringar. Ett av mina små projekt (på Python) Jag använde underscored_names för verktygsfunktioner / ”skyddade” metoder och Java-stil methodNames för metoder. Mitt team var nöjd med det 🙂

Beror på programmeringsspråket.

Jag överväger att använda fallet i samma båt för huruvida de ska använda ungerska notationer:

• Python: understrykningslåda, ingen ungerska notation
• C ++: camelCase, ungerska notation

Kommentarer

• @Kevin Cantu: Egentligen är namnet Javascript i PascalCase snarare än camelCase …
• @Guffa: tryck på é!
• @Kevin Cantu: på JavaScript: XMLHttpRequest < – Jag hatar det här namnet wi en passion.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: Egentligen används ungerska notationen nästan aldrig i C ++, eftersom C ++ redan kontrollerar dina typer. Det ' är mer av en historisk artefakt än någonting annat.

Båda!

Jag utvecklar mycket i CakePHP och använder antingen CamelCase eller $underscored_vars på följande sätt (även utanför CakePHP-projekt):

1. filnamn – /lowercased_underscored.php Typiskt men värt att nämna.
2. klasser – class CamelCase extends ParentObject. Observera att när du använder CamelCase är det ursprungliga tecknet inte gemener. Jag tycker att camelCase ser riktigt konstigt ut.
3. variabler – $are_variables_underscored === TRUE;
4. variabler som innehåller instanser – $CamelCase = new CamelCase();
5. arraynycklar – $collection["underscored_keys"];
6. konstanter – Jag tror alla kan komma överens om att konstanter ska vara ALL_CAPS_AND_UNDERSCORED.
7. metoder – $CamelCase->foo_method_underscored();
8. statiska metoder – CamelCase::just_like_regular_methods();

Kommentarer

• måste hålla med dig, med det första tecknet att vara lägre fall gör mig galen! Jag hatar camelCase med en passion.
• I Java där namnen typiskt är camelCased börjar klassnamnen faktiskt med en stor bokstav. Detta för att skilja dem från metodnamn.

Jag föredrar personligen underscore_case eftersom jag tycker att det är mer läsbart, men håller med de andra svararna som påpekar att överensstämmelse med den befintliga kodbasen är mycket viktigare.

Jag har dock ett motexempel för dem som säger ” följ konventionen för ditt språk och dess bibliotek ”.

Tidigare skrev vi C-kod i Windows med underscore_case och kallade PascalCase Win32-funktioner:

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

Den visuella skillnaden mellan våra funktionsnamn och Microsofts funktionsnamn var ett hjälp snarare än ett hinder, eftersom det visade tydligt när koden gick in i ”systemland”.

Dessutom kunde jag ändra min redaktörs syntaxmarkeringsregler för att visa dem i olika färger, vilket gav ytterligare visuella ledtrådar när jag försökte förstå okända delar av koden (eller till och med mina egna).

Jag gillar verkligen Dylans bara-normala-streck-eftersom-de-är-enkla att skriva-och-lätta – att läsa.

Gilla

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

Men jag antar att eftersom detta språk är ganska obskyr, så är det här lite av ämnet. .. 🙁

Kommentarer

• Jag är också trött på att trycka på shift för att skriva understreck.
• Detta är vanligtvis inte möjligt för variabelnamn, eftersom " – " vanligtvis betyder minus.

Jag lärde mig att använda camelCase på universitetet. Jag har använt några olika konventioner under de senaste åren men föredrar camelCase framför allt annat. Jag tror att jag kommer ihåg att jag läste någonstans att camelCase faktiskt är det lättaste att läsa och förstå.

Kommentarer

• ja det ' är inte lättare eftersom du läser någonstans, det ' är lättare eftersom det var den första du arbetade med och huvudsakligen eftersom du är mer van vid det, till exempel är jag ' bekvämare med understrykningslåda.
• som i i ' har läst att en studie gjordes och fann att den var bättre ..

Jag använder ibland en mix: module_FunctionName. Alla (icke-statiska) funktioner i mina moduler börjar med en modulförkortning.

Till exempel en funktion för att skicka buffertinnehåll på I2C-bussen:

i2c_BufferSend() 

Alternativet i2c_buffer_send visar inte tillräckligt stor skillnad mellan prefix och funktionsnamn. i2cBufferSend blandar i prefix för mycket (det finns ett stort antal I2C-funktioner i den här modulen).

i2c_Buffer_send kan dock ha varit ett alternativ.

Mitt svar är att du anpassar dig efter det som fungerar bäst för ditt projekt (ditt språk, din SW-arkitektur, …), och jag ville påpeka att det kan vara användbart att blanda dessa stilar.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. Jag_respekterar_faktan_som_något_ kunde_tänka_på annat sätt_men_Jag_för_verkligt_förstå_varför.

Kommentarer

• +1 för de sista 2 raderna, men jag rekommenderar inte att du kombinerar namngivningskonventioner, du bör hålla fast vid en ellerannat.
• Så länge konventionen är väl definierad (prefix + understrykning + PascalCase) …
• Jag vill använda understrykningar för att separera delar av ett namn som har semantiskt ojämnhet syften, särskilt om gemensamhet på båda hälften kan vara betydelsefull. Till exempel rutinerna Motor1_Start(), Motor2_Start(), Motor1_Stop() och Motor2_Stop() har en relation som kan vara mindre tydlig utan understrykningen.

Personligen , Jag föredrar camelCase, men i vissa teckensnitt tycker jag att understrykningar är lättare att läsa.

Jag föreslår att om du behöver använda prefix för att skilja olika variabler, ska du använda ett språk som låter dig skapa namnområden eller objekt eller något för att hålla den informationen.

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

På samma sätt, om du behöver skilja på olika typer, varför inte använda ett språk som tillåter dem?

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

När du har fått det rakt och du inte bara använder namnet som metadata, så har du inte tillräckligt långa namn för att det spelar mycket roll om du föredrar den extra tangenttryckningen eller inte.

Kommentarer

• En av anledningarna till att jag använder camelCase eller understrykning är att jag inte ' t måste hitta objektdefinitionen för att urskilja vad det är.

Till en början håller jag med dafmetal . Det är av yttersta vikt att du inte blandar olika programmeringsstilar. Att göra detta i en och samma fil är det värsta du kan göra IMHO. I olika filer är det distraherande, men inte dödligt.

Nästa sak du måste göra är att namnge regler som är populära för det språk du skriver på. Min C ++ -kod för instnace kommer att ser annorlunda ut än något för Python uppenbarligen (PEP8 är en trevlig guide här)

Du kan också använda olika namngivningskonventioner för att hänvisa till olika saker, så mycket som du förmodligen använder UPPER_CASE för konstanter (detta gäller bara vissa språk), kan du använda denna stil för lokala variabelnamn, medan du använder camelCase till exempel / medlemsvariabler. Detta kanske inte behövs när du har saker som self eller this.

Uppdatera

Låt oss ta ett fall där du har plattformen Foo witch rekommenderar inte några namnkonventioner och det är lagledarens val att välja en. Du är den lagledaren, varför skulle du välja camelCase eller varför understryka_case.

Det finns egentligen inga fördelar för varandra. Denna fråga är väldigt subjektiv och när den väl enats om kommer den inte att göra någon skillnad. Det finns alltid dessa religiösa krig om dessa små saker. Men när du väl har anpassat dig till något av dem, tycks diskussionerna vara helt överflödiga.

För att citera Alex Martelli i en mycket liknande fråga:

Visst, jag blir trött, i Ruby, av att skriva det dumma ”slutet” i slutet av varje block (snarare än bara oavbruten) – men då får jag undvika att skriva det lika dumma ”:” vilken Python kräver i början av början av varje block, så att ”det är nästan en tvätt :-). Andra syntaxskillnader som” @foo ”kontra” self.foo ”, eller den högre betydelsen av fall i Ruby vs Python är egentligen lika irrelevanta för mig.

Andra bygger utan tvekan sitt val av programmeringsspråk på just sådana frågor, och de genererar de hetaste debatterna – men för mig är det bara en exempel på en av Parkinsons lagar i aktion ( beloppet för debatt om en fråga är omvänt proportionell mot frågan ”s faktiska betydelse ).