Navngivningskonvensjoner: camelCase versus understrek_case? hva er tankene dine om det? [lukket]

Jeg er enig i at det avhenger av språket du bruker til en viss grad; koden har en tendens til å se penere ut når symbolnavnene dine har samme formatering diett som språket «innebygde og lagerbiblioteker.

Men der det er et valg, foretrekker jeg understrekninger fremfor kameltasker, av en enkel grunn: Jeg synes den stilen er lettere å lese. Her» s et eksempel: hva synes du er mer lesbart? Dette:

aRatherLongSymbolName 

eller dette:

a_rather_long_symbol_name 

Jeg finner understrekingsversjonen mye lettere å lese. Hjernen min kan ignorere understrekningene mye lettere enn den kan oppdage små / store bokstaver i kamelveske, spesielt der grensene er mellom tegn som ligner på andre tegn i motsatt sak, eller tall (I/l, O/0, t/I, etc). For eksempel lagrer denne boolske variabelen en verdi som indikerer om en Igloo er bygget med riktig planleggingstillatelse (utvilsomt en vanlig brukssak for oss alle):

isIllicitIgloo 

Jeg synes denne versjonen er mye lettere å lese:

is_illicit_igloo 

Kanskje enda verre enn et vanskelig å lese symbolnavn er et lett å lese feil navn. Gode symbolnavn er selvdokumenterende, noe som for meg betyr at du skal kunne lese dem og forstå betydningen av dem med et øyeblikk. (Jeg er sikker på at vi alle leser kodeutskrifter i sengen for fornøyelse, men noen ganger tøffer vi også i hast.) Jeg finner ofte med kamelveske symbolnavn at det er lett å lese dem feil og få feil inntrykk. av symbolet «s semantics.

Kommentarer

• Ett problem med understreker: brukervennlighet. For de fleste (europeiske) tastaturer krever å skrive understreket tegnet ned SHIFT-tasten. Du må også gjøre det for camelCase, men jeg kan komfortabelt holde SHIFT nede med pinky og skrive inn en hvilken som helst bokstav – men siden understrekingstasten er rett ved siden av SHIFT-tasten, er det å trykke begge samtidig ganske vanskelig og forstyrrer skrivestrømmen.
• For den første fant jeg faktisk camelCase lettere å lese – selv om sistnevnte åpenbart er annerledes.
• Dette avhenger faktisk av hva du ' er vant til. Jeg finner camelCases lettereToRead, og dessuten ' er kortere enn tilsvarende understrekingsnavn.
• Jeg hat å skrive understreker.
• " brukbarhet " punktet er irrelevant for dette. Koden skrives vanligvis bare én gang av en person, men la ' si i størrelsesorden 1-10 ganger og står for redigering og potensiell parprogrammering. Men kode blir vanligvis lest dusin / hundrevis / tusen ganger av en eller potensielt mange mennesker. Dermed er det enkelt å lese koden flere størrelser viktigere enn å ha koden lett å skrive.

Jeg synes du bør bruke navngivningskonvensjonen som er vedtatt av plattformen din. understrek_skap vil se rart ut i C # -koden, som camelCase i Ruby =)

Kommentarer

• Konsistens er en nøkkel. Enten du er enig med den lokale stevnet eller ikke, vil du gjøre din egen tid lettere (og alle andre ' s) ved å være konsistente. (Med mindre den lokale konvensjonen i seg selv ikke er inkonsekvens.) Også lesbarhet er stort sett et falskt argument: les nok kode som du ' vil oppdage at det er liten forskjell med mindre du bestemmer deg for at den er uleselig.
• Helt enig. Jeg tror bare det er bedre å bruke plattformkonvensjon i stedet for egendefinerte, fordi for eksempel nye gutter i teamet vil føle seg mer komfortable med det.
• Men ve dem som jobber på to plattformer med to konvensjoner. , der noen foretrekker og andre foretrekker den andre!
• Hvis plattformen har to stevner, ber jeg ' alle lagmedlemmer om å stemme på stevne de er komfortable med =)

Ærlig talt, det spiller ingen rolle så lenge alle på laget bruker Sjansen er stor at den ene eller den andre er mer naturlig for deg, selv om den virkelige viktigheten er lesbarhet av koden i det lange løp, og da er det avgjørende at alle følger de samme navneglene.

Kommentarer

• du har helt rett, men jeg ' Jeg prøver å finne ut folks mening om heks ville være bedre å bruke (la ' s for hele laget), og hvorfor … mens jeg forstår at noen mennesker bare kan være vant til noen konvensjoner, eller andre blir mer naturlige med den andre.

Generelt foretrekker jeg camelCase. Imidlertid er det fordi jeg i det meste av karrieren har jobbet i språk og miljøer der stilguider normalt anbefaler camelCase. (Java, ECMAScript, C ++). Du, som en PHP-person, vil sannsynligvis ha motsatt preferanse.

Når det er sagt, når du går utover treOrFourWords, eller hvis du bruker initialismer somXmlForExample, slutter det å være så lesbart.

Det er derfor emacs gir oss briller-modus.

Kommentarer

• +1 for å få meg til å oppdage briller-modus! Jeg testet det bare på en kodefil som bruker camelCase, og la merke til hvordan det umiddelbart begynte å se bedre ut (montering med mange etiketter i camelCase).
• Ok, hva er brille-modus?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Dette er et av de få stedene jeg alltid vil velge» type-evne «fremfor lesbarhet. CamelCase er bare lettere å skrive, og det å være bedre med fingrene mine vinner ut over en liten lesbarhetsgevinst for meg.

antar selvfølgelig at prosjektet ikke bygger på en eksisterende kodebase med en annen standard.

Kommentarer

• Jeg er ikke ' Jeg er ikke enig i det, du skriver bare kode én gang, men du må lese den flere ganger etterpå

Det er et interessant spørsmål, jeg har tenkt på dette mange ganger. Men det er ikke noe klart svar, tror jeg.

Etter de «kulturelle» konvensjonene er det et godt valg. «Kulturell» betyr i dette tilfellet konvensjoner satt opp i teamet / selskapet, og de bærer i utgangspunktet også språket / plattformkonvensjonene. Det hjelper andre å lese / bruke koden din enkelt og krever ikke ekstra innsats og tid for å komme i veien for å forstå koden din.

Noen ganger er det interessant å bryte aksepterte notasjoner. Et av mine små prosjekter. (på Python) brukte jeg underscored_names for verktøyfunksjoner / «beskyttede» metoder, og Java-stil methodNames for metoder. Teamet mitt var fornøyd med det 🙂

Avhenger av programmeringsspråket.

Jeg vurderer å bruke saken i den samme båten som skal bruke eller ikke bruke ungarsk notasjon:

• Python: understrek_skap, ingen ungarsk notasjon
• C ++: camelCase, ungarsk notasjon

Kommentarer

• @Kevin Cantu: Egentlig heter Javascript i PascalCase i stedet for camelCase …
• @Guffa: berør é!
• @Kevin Cantu: på JavaScript: XMLHttpRequest < – Jeg hater dette navnet wi en lidenskap.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: Egentlig er ungarske notasjoner nesten aldri brukt i C ++, siden C ++ allerede sjekker typene dine. Det ' er mer av en historisk gjenstand enn noe annet.

Begge!

Jeg utvikler mye i CakePHP, og bruker enten CamelCase eller $underscored_vars, på følgende måte (også utenfor CakePHP-prosjekter):

1. filnavn – /lowercased_underscored.php Typisk, men verdt å nevne.
2. klasser – class CamelCase extends ParentObject. Merk at når du bruker CamelCase, er ikke det første tegnet med små bokstaver. Jeg synes camelCase å se virkelig rart ut.
3. variabler – $are_variables_underscored === TRUE;
4. variabler som inneholder 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

• må være enig med deg, hvis det første tegnet er lavere saken gjør meg gal! Jeg hater camelCase med en lidenskap.
• I Java der navnene vanligvis er kamelforskyvet, begynner klassenavnene faktisk med en stor bokstav. Dette er for å skille dem fra metodenavn.

Jeg foretrekker personlig underscore_case fordi jeg synes det er mer leselig, men er enig med de andre svarerne som påpeker at konsistens med den eksisterende kodebasen er mye viktigere.

Jeg har imidlertid et moteksempel for de som sier » følg konvensjonen for språket ditt og dets biblioteker «.

Tidligere skrev vi C-kode på Windows ved hjelp av underscore_case, og kalte PascalCase Win32-funksjoner:

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

Det visuelle skillet mellom funksjonsnavnene våre og Microsofts funksjonsnavn var en hjelp snarere enn en hindring, da det viste tydelig når koden skulle inn i «systemland».

I tillegg var jeg i stand til å endre redigeringssyntaksens fremhevingsregler for å vise dem i forskjellige farger, noe som ga ytterligere visuelle ledetråder når jeg prøvde å forstå ukjente deler av koden (eller til og med mine egne).

Jeg liker Dylans bare normale streker, ettersom de er enkle å skrive og lette -til å lese.

Som

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

Men jeg antar at dette språket er ganske uklart, og dette er litt utenfor emnet. .. 🙁

Kommentarer

• Jeg er også lei av å trykke shift for å skrive understreker.
• Dette er vanligvis ikke mulig for variabelnavn, siden " – " vanligvis betyr minus.

Jeg ble lært å bruke camelCase på universitetet. Jeg har brukt noen forskjellige konvensjoner de siste årene, men foretrekker camelCase fremfor alt annet. Jeg tror jeg husker at jeg hadde lest et sted at camelCase faktisk er den letteste å lese og forstå.

Kommentarer

• vel det ' det er ikke lettere fordi du leser et sted, det ' det er lettere fordi det var den første du jobbet med og hovedsakelig fordi du er mer vant til det, for eksempel er jeg ' mer komfortabel med understreking_case.
• som i i ' har lest at en undersøkelse ble gjort og fant ut at den var bedre ..

Jeg bruker en blanding noen ganger: module_FunctionName. Alle (ikke-statiske) funksjoner i modulene mine starter med en modulforkortelse.

For eksempel en funksjon for sending av bufferinnhold på I2C-bussen:

i2c_BufferSend() 

Alternativet i2c_buffer_send viser ikke stor nok skille mellom prefiks og funksjonsnavn. i2cBufferSend blandes i prefiks for mye (det er ganske mange I2C-funksjoner i denne modulen).

i2c_Buffer_send kan ha vært et alternativ, skjønt.

Svaret mitt er at du tilpasser deg det som fungerer best for prosjektet ditt (språket ditt, din SW-arkitektur, …), og jeg ønsket å påpeke at det kan være nyttig å blande disse stilene. Jeg_respekterer_fakta_enom_kan_tinke_andres_men_jeg_for_virket_forstå_hvorfor.annet.

Personlig , Jeg foretrekker camelCase, men i noen skrifter tror jeg understrekninger er lettere å lese.

Jeg vil foreslå at hvis du trenger å bruke prefikser for å skille variabler, bør du bruke et språk som lar deg lage navneområder eller objekter eller noe som inneholder informasjonen.

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

På samme måte, hvis du trenger å skille mellom typer, hvorfor ikke bruke et språk som tillater det?

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

Når du har fått det rett, og du ikke bare bruker navnet som metadata, vil du ikke ha nok lange navn til at det betyr veldig mye om du foretrekker den ekstra tastetrykk eller ikke.

Kommentarer

• En av grunnene til at jeg bruker camelCase eller understrek_case er at jeg ikke ' t trenger å finne objektdefinisjonen for å skjelne hva den er.

Først er jeg enig med dafmetal . Det er av største betydning at du ikke blander forskjellige programmeringsstiler. Å gjøre dette i en og samme fil er det verste du kan gjøre IMHO. På tvers av forskjellige filer er det distraherende, men ikke dødelig.

Det neste du må gjøre er å navngi regler som er populære for språket du skriver på. Min C ++ -kode for instnace vil ser annerledes ut enn noe for Python åpenbart (PEP8 er en fin guide her)

Du kan også bruke forskjellige navnekonvensjoner for å referere til forskjellige ting, så mye som du sannsynligvis bruker UPPER_CASE for konstanter (dette gjelder bare for visse språk selvfølgelig), kan du bruke denne stilen for lokale variabelnavn, mens du bruker camelCase for eksempel / medlemsvariabler. Dette er kanskje ikke nødvendig når du har ting som self eller this.

Oppdater

La oss ta en sak der du har plattformen Foo heks ikke anbefaler noen navnekonvensjoner og det er teamlederens valg å velge en. Du er den teamlederen. Hvorfor velger du camelCase eller hvorfor understreker_case.

Det er ingen fordeler for hverandre egentlig. Denne saken er veldig subjektiv og når den enes om, vil den ikke utgjøre noen forskjell. Det er alltid disse religiøse krigene om disse små tingene. Men når du først er blitt justert til en av dem, synes diskusjonene å være helt overflødige.

For å sitere Alex Martelli om en veldig lik sak:

Visst, jeg blir trøtt, i Ruby, av å skrive den dumme «enden» på slutten av hver blokk (i stedet for bare unindenting) – men da får jeg unngå å skrive den like dumme «:» som Python krever ved starten av hver blokk, slik at «det er nesten en vask :-). Andre syntaksforskjeller som» @foo «versus» self.foo «, eller den høyere betydningen av saken i Ruby vs Python, er egentlig omtrent like irrelevante for meg.

Andre baserer uten tvil valget av programmeringsspråk på nettopp slike spørsmål, og de genererer de hotteste debattene – men for meg er det bare en eksempel på en av Parkinsons lover i aksjon ( beløpet for debatt om et spørsmål er omvendt proporsjonalt med problemet s faktiske betydning ).

Kilde

Hvis du er teamleder, går du bare med en. Siden den ene ikke har noen fordeler fremfor den andre, kan du bare kaste terninger eller velge det du liker mer.

Jeg leste for flere år siden at programmerere som ikke snakker engelsk som førstespråk, har en tendens til å finne understreket sak lettere å forstå det kamel tilfellet – men jeg kan ikke finne referansen, og jeg aner ikke om det er sant.

For programmeringsspråk jeg har brukt, som Java, Python, C ++, har jeg vedtatt et klart format:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Dette gjør at jeg kan umiddelbart forstå hva jeg har å gjøre med. Jeg har funnet ut at det er nyttig å opprettholde for meg selv, og det skal være enkelt å følge for noen andre som leser koden. Jeg tror som andre nevnte konsistens er viktigst. Så jeg finner formatet mitt for å være enkel nok til å opprettholde, samtidig som jeg skiller tydelige skiller mellom typer navn. Jeg kunne forestille meg interface_Names_Are_Like_This og Abstract_Classes_Are_Like_This som mulige utvidelser, men ser ut til å være mer komplisert å følge og kanskje ikke så nyttig et skille å gjøre. > Jeg har også funnet det nyttig å være streng og nevne ting i PascalCase, for eksempel en HTML-parser som HtmlParser i stedet for HTMLParser eller HTMLparser. Fordi jeg tror det er lettere å huske den strenge regelen og holder ordgrensene tydeligere (dessverre krever det feilstavede ting som HTML eller SQL). Tilsvarende med camelCase, htmlParserMethod i stedet for HTMLParserMethod eller HTMLparserMethod.

UPDATE :

Jeg har siden funnet bruk for å utvide disse reglene til å omfatte private variabler.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

I Java betyr dette at private felt per definisjon er i et annet navneområde enn lokale variabler, noe som betyr at du kan hoppe over 4 div = » Enger. Andre formater Jeg har sett prefiks med «m«, men disse formatene bruker også camelCase for variabelnavnene. Dette gjør det også mulig for meg å skille mellom felt som bare skal være tilgjengelig internt av klassen (og gjør det super klart når det skjer utenfor klassen object._field_x skiller seg ut).

Hvis det var opp til meg, ville jeg ikke håndheve eller antyde at bruken av en hvilken som helst bestemt stil fordi vi som programmerere kunne lese et symbol IfItIsInCamelCase eller in_underscore_space eller til og med in_SomeOtherStyle og forstå hva det betyr. Å måtte bruke litt tid på å analysere symbolet er ingen stor kostnad i det store opplegget av ting.

Nå er hovedargumentet for en konvensjon at du vet på forhånd hva formatet til et funksjons- / variabelnavn er og ikke trenger å slå opp – er det LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Nå vil jeg motvirke dette argumentet ved å si «Få en IDE som støtter automatisk fullføring av intellisense-stil!» (ikke alltid mulig skjønt).

Til slutt spiller det imidlertid ingen rolle hvilken stil du bruker, fordi kompilatoren / tolk ikke bryr seg veldig. Det som er viktig er at navnet er nyttig:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Tre forskjellige stiler, men du vet nøyaktig hva hver enkelt gjør.

Kommentarer

• Jeg ber om å være annerledes, kildens utseende er viktig. Se " Den pragmatiske programmereren " ' teorien om ødelagte vinduer. Varierende navngivningskonvensjon gjør utseendet verre. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Selv om jeg er enig med ' ødelagt vindu ' idé, jeg tror ikke ' t tror at store bokstaver i symboler utgjør en ' ødelagt vindu '. Tilfeldig lagt kode er det absolutt, og mitt nåværende prosjekt har absolutt mye av det som jeg prøver å rydde opp når jeg kan.
• Jeg er enig. Jeg kan lese alle tre like godt. Det betyr ikke ' t. Jeg bruker bare hva filen bruker, så uansett hva språket foreslår (python) og deretter det jeg føler at prosjektet vil bli best tjent med. (Jeg pleide å programmere på gwbasic, og det var alt sammen store og små – de gamle gode dager!)

Kan virke dumt, men jeg liker ikke understrekninger fordi understrekningen er tynn og gjemmer seg i tekst med flere linjer, og jeg savner den. Også i noen (mange) tekstredigerere og / eller utviklingsmiljøer når du dobbeltklikker på et tokenavn for å markere det for å kopiere eller dra og slippe det, systemet vil ikke markere hele tokenet, det fremhever bare en del av tokenet, mellom tilstøtende understreker. Det gjør meg nøtt.

Jeg pleier å foretrekke camelCase av den dumme grunnen til at jeg gjør det meste av utviklingen min i Eclipse (For Java, PHP og JavaScript), og når jeg Ctrl + ← eller Ctrl + → gjennom ord, det stopper faktisk ved kamelCase-grensene.

Ie: myIntVariable vil bli behandlet av formørkelse som 3 ord når Ct rl + ←   → » gjennom det.

Jeg vet at det er en merkelig særeie, men jeg foretrekker å kunne redigere mellomordene i et kamelNavn.