Navngivningskonventioner: camelCase versus understregning_case? hvad er dine tanker om det? [lukket]

Jeg er enig i, at det afhænger af det sprog, du bruger til en vis grad; kode har tendens til at se pænere ud, når dine symbolnavne følger den samme formatering regime som sproget “indbyggede biblioteker og lagerbiblioteker.

Men hvor der er et valg, foretrækker jeg understregning frem for kamelhus af en simpel grund: Jeg finder den stil lettere at læse. Her” s et eksempel: hvad finder du mere læsbart? Dette:

aRatherLongSymbolName 

eller dette:

a_rather_long_symbol_name 

Jeg finder understregningsversionen meget lettere at læse. Min hjerne kan ignorere understregningerne meget lettere, end den kan registrere små / store bogstaver i kameltasker, især hvor grænserne er mellem tegn, der ligner andre tegn i det modsatte tilfælde, eller tal (I/l, O/0, t/I osv.). For eksempel gemmer denne boolske variabel en værdi, der angiver, om en Igloo er blevet bygget med korrekt planlægningstilladelse (uden tvivl en almindelig brugssag for os alle):

isIllicitIgloo 

Jeg finder denne version en masse lettere at læse:

is_illicit_igloo 

Måske endnu værre end et svær at læse symbolnavn er et let at mislæse symbolnavn. Gode symbolnavne er selvdokumenterende, hvilket for mig betyder, at du skal kunne læse dem og forstå deres mening med det samme. (Jeg er sikker på, at vi alle læser kodeudskrifter i sengen for fornøjelse, men lejlighedsvis groker vi også i hast.) Jeg finder ofte navne på kamelæske, at det er let at læse dem forkert og få det forkerte indtryk. af et symbol “s semantik.

Kommentarer

• Et problem med understregning: brugervenlighed. For de fleste (europæiske) tastaturer kræves det, at du skriver understregetegn nede på SHIFT-tasten. Det skal du også gøre for camelCase, men jeg kan komfortabelt holde SHIFT nede med pinken og skrive et hvilket som helst bogstav – men da understregningstasten er lige ved siden af SHIFT-tasten, er det at trykke begge på samme tid ret akavet og afbryder strømmen af skrivning.
• For det første fandt jeg faktisk camelCase lettere at læse – selvom sidstnævnte naturligvis er anderledes.
• Dette afhænger faktisk af, hvad du ' er vant til. Jeg finder camelCases lettereToRead, og desuden er de ' kortere end ækvivalente understregningsnavne.
• Jeg hader at skrive understregninger.
• " anvendelighed " punktet er irrelevant for dette. Koden skrives typisk kun én gang af en person, men lad ' sige i størrelsesordenen 1-10 gange og tegne sig for en del redigering og potentiel parprogrammering. Men kode læses typisk dusin / hundreder / tusinder af gange af en eller potentielt mange mennesker. Således er det let at læse kode flere størrelser vigtigere end at have kode let at skrive.

Jeg synes, du skal bruge navngivningskonvention, der er vedtaget af din platform. understregning_case vil se underlig ud i C # -kode, som camelCase i Ruby =)

Kommentarer

• Konsistens er en nøgle. Uanset om du er enig med den lokale konvention eller ej, vil du gøre din egen tid lettere (og alle andre ' s) ved at være konsistente. (Medmindre den lokale konvention i sig selv er inkonsekvens.) Også læsbarhed er for det meste et falsk argument: læs nok kode, som du ' finder ud af, at der er lille forskel, medmindre du beslutter, at den er ulæselig. / li>
• Helt enig. Jeg tror bare, at det er bedre at bruge platformskonvention i stedet for brugerdefinerede, for for eksempel vil nye fyre i teamet føle sig mere komfortable med det.
• Men ve dem, der arbejder på to platforme med to konventioner , hvor nogle foretrækker og andre foretrækker den anden!
• Hvis platform har to konventioner, beder jeg ' alle holdmedlemmer om at stemme på en konvention, de er fortrolige med =)

Helt ærligt betyder det ikke rigtig noget, så længe alle i holdet bruger Det samme skema. Chancerne er, at den ene eller den anden er mere naturlig for dig, selvom den virkelige betydning er læsbarhed af kode i det lange løb, og så er det afgørende, at alle overholder de samme navngivningsregler.

Kommentarer

• du har ret i alt, men jeg ' Jeg prøver at finde ud af folks mening om heks ville være bedre at bruge (lad ' siger for hele holdet), og hvorfor … mens jeg forstår, at nogle mennesker måske bare er vant til en eller anden konvention, eller andre er mere naturlige med den anden.

Generelt foretrækker jeg camelCase. Det skyldes imidlertid, at jeg i det meste af min karriere arbejder på sprog og miljøer, hvor stilguiderne normalt anbefaler camelCase. (Java, ECMAScript, C ++). Du, som PHP-person, har sandsynligvis den modsatte præference.

Når det er sagt, når du går ud over treOrFourWords, eller hvis du bruger initialismer som XmlForExample, holder det op med at være så læsbart.

Det er derfor, emacs giver os en brille-tilstand.

Kommentarer

• +1 for at få mig til at opdage briller-tilstand! Jeg testede det lige på en kodefil, der bruger camelCase, og bemærkede, hvordan det straks begyndte at se bedre ud (samling med masser af etiketter i camelCase).
• Okay, hvad er brille-mode?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Dette er et af de få steder, hvor jeg altid vælger” type-evne “frem for læsbarhed. CamelCase er bare lettere at skrive, og det at være pænere over for mine fingre vinder ud over en let læsbarhedsgevinst for mig.

forudsætter naturligvis, at projektet ikke bygger på en eksisterende kodebase med en anden standard.

Kommentarer

• Jeg er ikke ' det er jeg ikke enig i, du skriver kun kode én gang, men du skal læse den flere gange bagefter

Det er et interessant spørgsmål, jeg har tænkt på dette mange gange. Men der er ikke noget bestemt svar, tror jeg.

Efter de “kulturelle” konventioner er det et godt valg. “Kulturel” betyder i dette tilfælde konventioner, der er oprettet i teamet / virksomheden, og de bærer dybest set også sprog / platformskonventionerne. Det hjælper andre med at læse / bruge din kode let og kræver ikke yderligere indsats og tid til at komme i vejen for at forstå din kode.

Nogle gange er det interessant at bryde accepterede notationer. Et af mine små projekter. (på Python) brugte jeg underscored_names til hjælpefunktioner / “beskyttede” metoder og Java-stil methodNames til metoder. Mit team var tilfreds med det 🙂

Afhænger af programmeringssprog.

Jeg overvejer at bruge sagen i den samme båd, hvorvidt der skal bruges ungarsk notation eller ej:

• Python: understregningstaske, ingen ungarsk notation
• C ++: camelCase, ungarsk notation

Kommentarer

• @Kevin Cantu: Navnet Javascript er faktisk i PascalCase snarere end camelCase …
• @Guffa: tryk på é!
• @Kevin Cantu: på JavaScript: XMLHttpRequest < – Jeg hader dette navn wi en lidenskab.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: Faktisk er ungarsk notation næsten aldrig brugt i C ++, da C ++ allerede kontrollerer dine typer. Det ' er mere af en historisk artefakt end noget andet.

Begge!

Jeg udvikler meget i CakePHP, og jeg bruger enten CamelCase eller $underscored_vars på følgende måde (også uden for CakePHP-projekter):

1. filnavne – /lowercased_underscored.php Typisk, men værd at nævne.
2. klasser – class CamelCase extends ParentObject. Bemærk, at når du bruger CamelCase, er det oprindelige tegn ikke med små bogstaver. Jeg finder camelCase til at se virkelig underligt ud.
3. variabler – $are_variables_underscored === TRUE;
4. variabler, der indeholder forekomster – $CamelCase = new CamelCase();
5. array-taster – $collection["underscored_keys"];
6. konstanter – jeg tror alle kan være enige om, at konstanter skal være ALL_CAPS_AND_UNDERSCORED.
7. metoder – $CamelCase->foo_method_underscored();
8. statiske metoder – CamelCase::just_like_regular_methods();

Kommentarer

• skal være enige med dig, hvis det første tegn er lavere sag gør mig skør! Jeg hader camelCase med en lidenskab.
• I Java, hvor navne typisk er camelCased, begynder klassens navne faktisk med et stort bogstav. Dette er for at skelne dem fra metodens navne.

Jeg foretrækker personligt underscore_case fordi jeg finder det mere læsbart, men er enig med de andre svarere, der påpeger, at konsistens med den eksisterende kodebase er meget vigtigere.

Jeg har dog et modeksempel for dem, der siger ” følg konventionen af dit sprog og dets biblioteker “.

Tidligere skrev vi C-kode på Windows ved hjælp af underscore_case og kaldte PascalCase Win32-funktioner:

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

Den visuelle forskel mellem vores funktionsnavne og Microsofts funktionsnavne var en hjælp snarere end en hindring, da det viste tydeligt, hvornår koden skulle ind i “systemland”.

Derudover var jeg i stand til at ændre min redaktørs syntaksfremhævelsesregler for at vise dem i forskellige farver, hvilket gav yderligere visuelle spor, når jeg forsøgte at forstå ukendte sektioner af kode (eller endda mine egne).

Jeg kan virkelig godt lide Dylans bare normale streger, da de er lette at skrive og lette -til at læse.

Ligesom

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

Men jeg antager, at da dette sprog er temmelig uklart, er dette en slags uden for emnet. .. 🙁

Kommentarer

• Jeg er også træt af at trykke på shift for at skrive understregninger.
• Dette er normalt ikke muligt for variabelnavne, da " – " normalt betyder minus.

Jeg lærte at bruge camelCase på universitetet. Jeg har brugt et par forskellige konventioner i løbet af de sidste par år, men foretrækker camelCase frem for alt andet. Jeg tror, jeg husker at have læst et eller andet sted, at camelCase faktisk er den nemmeste at læse og forstå.

Kommentarer

• godt det ' det er ikke lettere, fordi du læser et eller andet sted, det ' det er lettere, fordi det var den første, du arbejdede med og hovedsagelig fordi du er mere vant til det, for eksempel er jeg ' m mere komfortabel med understregningstaske.
• som i i ' har læst, at en undersøgelse blev udført, og fandt det bedre ..

Jeg bruger nogle gange en blanding: module_FunctionName. Alle (ikke-statiske) funktioner i mine moduler starter med en modulforkortelse.

For eksempel en funktion til at sende et bufferindhold på I2C-bussen:

i2c_BufferSend() 

Alternativet i2c_buffer_send viser ikke en stor nok adskillelse mellem præfiks og funktionsnavn. i2cBufferSend blandes i prefix for meget (der er et stort antal I2C-funktioner i dette modul).

i2c_Buffer_send kunne dog have været et alternativ.

Mit svar er, at du tilpasser dig det, der fungerer bedst til dit projekt (dit sprog, din SW-arkitektur, …), og jeg vil gerne påpege, at det kan være nyttigt at blande disse stilarter.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. Jeg_respekterer_fakta_den_en_kal_tænke_en anden_but_I_do_ikke_ virkelig_forstår_hvorfor.

Kommentarer

• +1 til de sidste 2 linjer, men jeg anbefaler ikke, at du kombinerer navngivningskonventioner, du skal holde fast ved en ellerandet.
• Så længe konventionen er veldefineret (præfiks + understregning + PascalCase) …
• Jeg kan godt lide at bruge understregninger til at adskille dele af et navn, der har semantisk uensartet formål, især hvis fælles i begge halvdele kan være væsentlig. For eksempel er rutinerne Motor1_Start(), Motor2_Start(), Motor1_Stop() og Motor2_Stop() har et forhold, der måske er mindre klart uden understregningerne.

Personligt , Jeg foretrækker camelCase, men i nogle skrifttyper synes jeg understregninger er lettere at læse.

Jeg vil foreslå, at hvis du har brug for præfikser til at differentiere sæt variabler, skal du bruge et sprog, der giver dig mulighed for at oprette navneområder eller objekter eller noget, der indeholder disse oplysninger.

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

Ligeledes, hvis du har brug for at differentiere typer, hvorfor ikke bruge et sprog, der tillader dem?

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

Når du har det lige, og du ikke bare bruger navnet som metadata, har du ikke nok lange navne til at det betyder meget, om du foretrækker det ekstra tastetryk eller ej.

Kommentarer

• En af grundene til at bruge camelCase eller understregning er, at jeg ikke ' t har brug for at finde objektdefinitionen for at skelne, hvad det er.

Først er jeg enig med dafmetal . Det er af største vigtighed, at du ikke blander forskellige programmeringsstile. At gøre dette i en og samme fil er det værste, du kan gøre IMHO. På tværs af forskellige filer er det distraherende, men ikke fatal.

Den næste ting du skal gøre er at navngive regler, der er populære for det sprog, du skriver på. Min C ++ -kode til instnace vil ser anderledes ud end noget for Python åbenbart (PEP8 er en god guide her)

Du kan også bruge forskellige navngivningskonventioner til at henvise til forskellige ting, så meget som du sandsynligvis bruger UPPER_CASE til konstanter (dette gælder kun for visse sprog naturligvis), kan du bruge denne stil til lokale variabelnavne, mens du bruger camelCase for eksempel / medlemsvariabler. Dette er muligvis ikke nødvendigt, når du har ting som self eller this.

Opdater

Lad os tage en sag, hvor du har platformen Foo heks anbefaler ikke nogen navngivningskonventioner, og det er teamlederens valg at vælge en. Du er den holdleder, hvorfor vælger du camelCase eller hvorfor understreger_case.

Der er virkelig ingen fordele for den ene over den anden. Denne sag er meget subjektiv, og når den først er aftalt, vil den ikke gøre en forskel. Der er altid disse religiøse krige om disse små ting. Men når du først er blevet tilpasset til en af dem, synes diskussionerne at være helt overflødige.

For at citere Alex Martelli om en meget lignende sag:

Sikker på, jeg bliver træt i Ruby af at skrive den fjollede “ende” i slutningen af hver blok (snarere end bare uhindret) – men så undgår jeg at skrive det lige så fjollede “:” hvilket Python kræver ved start for hver blok, så “det er næsten en vask :-). Andre syntaksforskelle såsom” @foo “versus” self.foo “eller den højere betydning af sager i Ruby vs Python er virkelig lige så irrelevante for mig.

Andre baserer uden tvivl deres valg af programmeringssprog på netop sådanne spørgsmål, og de genererer de hotteste debatter – men for mig er det bare en eksempel på en af Parkinsons love i aktion ( beløbet til debat om et emne er omvendt proportionalt med emnet “s faktiske betydning ).

Kilde

Hvis du er teamleder, går du bare med en. Da den ene ikke har nogen fordele i forhold til den anden, kan du bare kaste terninger eller vælge det, du kan lide mere.

Jeg læste for flere år siden, at programmører, der ikke taler engelsk som førstesprog, har tendens til at finde understregede tilfælde lettere at forstå det kameltaske, men jeg kan ikke finde referencen, og jeg aner ikke, om det er sandt.

Til programmeringssprog, som jeg har brugt, som Java, Python, C ++, har jeg vedtaget et klart format:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Dette giver mig mulighed for skel straks, hvad jeg har at gøre med. Jeg har fundet ud af, at det er nyttigt at vedligeholde for mig selv, og det skal være let at følge for en anden, der læser koden. Jeg synes, som andre nævnte, at konsistens er vigtigst. for at være enkel nok til at vedligeholde, samtidig med at jeg skelner tydeligt mellem typer af navne. Jeg kunne forestille mig interface_Names_Are_Like_This og Abstract_Classes_Are_Like_This som mulige udvidelser, men synes at være mere kompliceret at følge og måske ikke så brugbar en forskel at gøre. > Jeg har også fundet det nyttigt at være streng og navngive ting i PascalCase såsom en HTML-parser som HtmlParser i stedet for HTMLParser eller HTMLparser. Fordi jeg mener, at det er lettere at huske den strenge regel og holder ordgrænserne klarere (desværre kræver det stavefejl som HTML eller SQL). På samme måde med camelCase, htmlParserMethod i stedet for HTMLParserMethod eller HTMLparserMethod.

UPDATE :

Jeg har siden fundet brug for at udvide disse regler til at omfatte private variabler.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

I Java betyder det, at private felter pr. definition er i et andet navneområde end lokale variabler, hvilket betyder, at du kan springe over 4 div = ” felter. Andre formater Jeg har set præfikset med m “, men disse formater bruger også camelCase til variabelnavne. Dette giver mig også mulighed for at skelne mellem felter, der kun skal åbnes internt af klassen (og gør det super klart, når det sker uden for klassen object._field_x skiller sig ud).

Hvis det skyldtes mig, ville jeg ikke håndhæve eller antyde at brugen af en bestemt stil, fordi vi som programmører kunne være i stand til at læse et symbol IfItIsInCamelCase eller in_underscore_space eller endda in_SomeOtherStyle og forstå, hvad det betyder. At skulle bruge lidt tid på at parsere symbolet er ikke noget stort overhead i det store skema af ting.

Nu er hovedargumentet for en konvention gætte, at du på forhånd ved, hvad formatet på et funktions- / variabelnavn er, og ikke behøver at slå det op – er det LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Nu vil jeg modvirke dette argument ved at sige “Få en IDE, der understøtter automatisk afslutning af intellisense-stil!” (ikke altid muligt dog).

I sidste ende betyder det dog ikke noget, hvilken stil du bruger, fordi compileren / tolken ikke er ligeglad. Hvad der er vigtigt er, at navnet er nyttigt:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Tre forskellige stilarter, men du ved præcis, hvad hver enkelt gør.

Kommentarer

• Jeg beder om at afvige, kildeudseendet er vigtigt. Se " Den pragmatiske programmerer " ' teori om brudte vinduer. Varierende navngivningskonvention gør udseendet værre. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Selvom jeg er enig med ' brudt vindue ' idé, jeg tror ikke ' t mener, at store bogstaver udgør en ' ødelagt vindue '. Det er bestemt tilfældigt lagt kode, og mit nuværende projekt har bestemt meget af det, som jeg prøver at rydde op, når jeg kan.
• Jeg er enig. Jeg kan læse alle tre lige så godt. Det betyder ikke ' t. Jeg bruger bare hvad filen bruger, så uanset hvilket sprog der foreslås (python), og så uanset hvad jeg føler, vil projektet være bedst tjent med. (Jeg plejede at programmere på gwbasic, og det hele var store bogstaver – de gode gamle dage!)

Kan virke fjollet, men jeg kan ikke lide understregninger, fordi understregningen er tynd og gemmer sig i tekst med flere linjer, og jeg savner den. Også i nogle (mange) teksteditorer og / eller dev-miljøer, når du dobbeltklikker på et tokenavn for at fremhæve det for at kopiere eller trække og slippe det, systemet fremhæver ikke hele token, det fremhæver kun en del af tokenet mellem tilstødende understregninger. Det gør mig nødder.

Jeg plejer at foretrække camelCase af den dumme grund, at jeg gør det meste af min udvikling i Eclipse (til Java, PHP og JavaScript), og når jeg Ctrl + ← eller Ctrl + → gennem ord stopper det faktisk ved camelCase-grænserne.

Dvs. myIntVariable ville blive behandlet af formørkelse som 3 ord, når Ct rl + ←   → ” igennem det.

Jeg ved, det er en underlig finurlighed, men jeg foretrækker at være i stand til at redigere mellemordene i et camelCase-navn.