Convenții de denumire: camelCase versus underscore_case? ce părere ai despre asta? [închis]

Pe baza unui răspuns, răspunsul lui John Isaacks:

„sincer codul este mai ușor de citit” Opinie sau fapt?

Am decis să fac unele cercetări și am găsit această lucrare . Ce are de spus știința pe această temă?

1. Carcasa cămilei are o probabilitate mai mare de corectitudine decât subliniază. (cotele sunt cu 51,5% mai mari)
2. În medie, cazul cămilă a durat cu cu 0,42 secunde mai mult Cu 13,5% mai mult.
3. Antrenamentul nu are un impact semnificativ statistic asupra modului în care stilul influențează corectitudinea.
4. Cei cu instruire mai rapidă au fost pe identificatori în stilul cămilă.
5. Antrenamentul într-un singur stil, afectează negativ timpul de găsire pentru alte stiluri.

În postarea mea pe blog pe subiect revizuiesc lucrare științifică și faceți următoarea concluzie.

Numai lentitudinea cazului de cămilă ( 2) este cu adevărat relevant pentru programare, respingând celelalte puncte ca fiind irelevante din cauza IDE-urilor moderne și a majorității utilizatorilor camelCase din studiu. Discuția (împreună cu un sondaj) poate fi găsită pe postarea de pe blog.

Sunt curios cum acest articol ar putea schimba părerea. 🙂

Comentarii

• Bineînțeles, respingeți toate celelalte puncte din cauza preferinței dvs. pentru subliniere și celelalte puncte nu vă ajută ' să vă ajute cazul …
• @Charles: Da și nu, IMHO fac argumente bune de ce sunt respinse, iar unele dintre ele sunt chiar discutate ca problematice de către lucrarea în sine. A lucrare de urmărire investighează unele dintre problemele acestei lucrări , iar rezultatele sunt pro-subliniere.

Copiați cei mai inteligenți tipi

În cazul limbajelor de programare, copiați stilul dezvoltatorului limbajului.

De exemplu codez C exact așa cum se face în K & R.

Apoi când cineva încearcă să înceapă o codare plictisitoare conversație stilistică, le pot spune „aduce asta cu Dennis Ritche și anunță-mă ce spune el.”

Comentarii

• Originalul nu este întotdeauna cel mai bun. Există multe practici rele în cartea Evangheliei K & R despre C. Înainte ca acesta să înceapă un război cu flăcări … citiți câteva dintre recomandările MISRA.
• Nu itați ' nu uitați, K & R a fost scris când nu există GUI-IDE. Cele mai multe lucrări s-au făcut pe terminale de 80×25 caractere, astfel încât spațiul pe ecran a fost la o valoare superioară, ceea ce a salvat if (...) { o linie! În aceste zile, există ' spațiu mai mare pe ecran – K & R ar fi diferit dacă este scris astăzi cu IDE-uri GUI de înaltă rezoluție și cu monitor amenajări?
• Da, dar când cineva spune că codifică C ca K & R, primesc recuzită pentru că sunt vechi.
• @quickly_now , aduceți asta cu Dennis Ritchie și spuneți-mi ce spune!
• Adopt o mulțime de formatări din MS: _internalToClassOnly, accessibleByGetter, PublicVariable.

În general, prefer camelCase. Cu toate acestea, acest lucru se datorează faptului că cea mai mare parte a carierei mele am lucrat în limbi și medii în care ghidurile de stil recomandă în mod normal camelCase. (Java, ECMAScript, C ++). Dvs., fiind persoană PHP, este probabil să aveți preferința opusă.

Acestea fiind spuse, atunci când treci dincolo de threeOrFourWords sau dacă folosești inițialisme precum XMLPentruExemplu, acesta nu mai este atât de lizibil.

De aceea emacs ne oferă ochelari-mod. h3> Comentarii

• +1 pentru că m-a făcut să descopăr modul ochelari! Tocmai l-am testat pe un fișier de cod care folosește camelCase și am observat cum a început imediat să arate mai bine (asamblare cu o mulțime de etichete în camelCase).
• Bine, ce este modul ochelari?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Acesta este unul dintre puținele locuri în care voi alege întotdeauna„ tip-abilitate ”peste lizibilitate. CamelCase este mai ușor de tastat, iar faptul că sunt mai drăguț cu degetele câștigă un câștig ușor de citire pentru mine.

presupunând, desigur, că proiectul nu se bazează pe o bază de cod existentă cu un standard diferit.

Comentarii

• Nu ' nu sunt de acord cu asta, scrii cod o singură dată, dar trebuie să-l citești de mai multe ori după aceea

Este o întrebare interesantă, m-am gândit la asta de multe ori. Dar nu există un răspuns clar, cred.

În urma convențiilor „culturale”, este o alegere bună. „Cultural”, în acest caz, înseamnă convenții înființate în echipă / companie și, practic, conțin și convențiile de limbă / platformă. Îi ajută pe ceilalți să citească / să utilizeze codul dvs. cu ușurință și nu necesită eforturi suplimentare și timp pentru a intra în modul de înțelegere a codului dvs.

Uneori este interesant să rupeți notațiile acceptate. Unul dintre proiectele mele mici (pe Python) am folosit underscored_names pentru funcții utilitare / metode „protejate” și stil Java methodNames pentru metode. Echipa mea a fost fericită cu ea 🙂

Depinde de limbajul de programare.

Consider că folosesc cazul în aceeași barcă de a utiliza sau nu notația maghiară:

• Python: underscore_case, fără notația maghiară
• C ++: camelCase, notația maghiară

Comentarii

• @ Kevin Cantu: De fapt, numele Javascript este mai degrabă în PascalCase decât camelCase …
• @Guffa: atinge é!
• @Kevin Cantu: pe JavaScript: XMLHttpRequest < – Urăsc acest nume wi o pasiune.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: De fapt, notația maghiară nu este aproape niciodată folosită în C ++, deoarece C ++ verifică deja tipurile dvs. ' este mai mult un artefact istoric decât orice altceva.

Ambele!

Fac multă dezvoltare în CakePHP și folosesc fie CamelCase, fie $underscored_vars, în modul următor (chiar și în afara proiectelor CakePHP):

1. nume de fișiere – /lowercased_underscored.php Tipic, dar merită menționat.
2. clase – class CamelCase extends ParentObject. Rețineți că, atunci când utilizați CamelCase, caracterul inițial nu este cu litere mici. Mi se pare camelCase să pară cu adevărat ciudat.
3. variabile – $are_variables_underscored === TRUE;
4. variabile care conțin instanțe – $CamelCase = new CamelCase();
5. chei matrice – $collection["underscored_keys"];
6. constante – cred toată lumea poate fi de acord că constantele ar trebui să fie ALL_CAPS_AND_UNDERSCORED.
7. metode – $CamelCase->foo_method_underscored();
8. metode statice – CamelCase::just_like_regular_methods();

Comentarii

• trebuie să fie de acord cu dvs., având primul caracter mai mic carcasa ma innebunește! Urăsc camelCase cu pasiune.
• În Java, unde numele sunt de obicei camelCased, numele claselor încep de fapt cu o majusculă. Aceasta este pentru a le distinge de numele metodelor.

Personal prefer underscore_case pentru că mi se pare mai lizibil, dar sunt de acord cu ceilalți respondenți care subliniază că coerența cu baza de cod existentă este mult mai importantă.

Cu toate acestea, am un contraexemplu pentru cei care spun „ urmați convenția limbii dvs. și a bibliotecilor sale „.

În trecut am scris codul C pe Windows folosind underscore_case și am numit PascalCase Funcțiile Win32:

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

Distincția vizuală între numele funcțiilor noastre și numele funcțiilor Microsoft a fost mai degrabă un ajutor decât un obstacol, deoarece a arătat în mod clar când codul intra în „sistem de aterizare”.

În plus, am putut schimba regulile de evidențiere a sintaxei editorului pentru a le afișa în diferite culori, ceea ce a oferit indicii vizuale suplimentare atunci când încerc să să înțeleg secțiuni de cod necunoscute (sau chiar ale mele).

Îmi place foarte mult liniuțele-normale-normale ale lui Dylan așa cum sunt ușor de tipat și ușor -to-read.

Like

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

Dar cred că acest limbaj este destul de obscur, acesta este un fel de off-topic. .. 🙁

Comentarii

• De asemenea, sunt obosit să apăs tasta pentru tastarea sublinierilor.
• În mod obișnuit, acest lucru nu este posibil pentru numele variabilelor, deoarece " – " înseamnă de obicei minus.

Am fost învățat să folosesc camelCase la universitate. „Am folosit câteva convenții diferite în ultimii ani, dar prefer camelCase decât orice altceva. Cred că îmi amintesc că am citit undeva că camelCase este de fapt cel mai ușor de citit și de înțeles.

Comentarii

• ei ' nu este mai ușor pentru că citești undeva, ' e mai ușor pentru că a fost primul cu care ați lucrat și, în principal, pentru că sunteți mai obișnuiți, de exemplu, eu ' m sunt mai confortabil cu underscore_case.
• ca în i ' Am citit că s-a făcut un studiu și l-am găsit mai bun ..

Așa cum au menționat majoritatea oamenilor – Utilizați standardul existent. Dacă este un proiect nou, utilizați standardul pentru limba și cadrele pe care le veți folosi.

Și nu vă confundați, nu este vorba de lizibilitate (care este subiectivă), ci de a fi consecvent și profesional. Oricine a lucrat într-o bază de cod cu numeroase „standarde” în desfășurare va înțelege.

Uneori folosesc un mix: module_FunctionName. Toate funcțiile (nestatice) din modulele mele încep cu o abreviere a modulului.

De exemplu, o funcție pentru trimiterea conținutului unui buffer pe magistrala I2C:

i2c_BufferSend() 

Alternativa i2c_buffer_send nu arată o separare suficient de mare între prefix și numele funcției. i2cBufferSend se amestecă în prefix prea mult (există un număr destul de mare de funcții I2C în acest modul).

i2c_Buffer_send ar putea fi o alternativă, totuși.

Răspunsul meu este că vă adaptați la ceea ce funcționează cel mai bine pentru proiectul dvs. (limba dvs., arhitectura dvs. SW, …) și am vrut să subliniez că amestecarea acestor stiluri ar putea fi utilă.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Comentarii

• +1 pentru ultimele 2 rânduri, totuși nu vă recomand să combinați convențiile de denumire, ar trebui să rămâneți cu una sau cualtele.
• Atâta timp cât convenția este bine definită (prefix + subliniere + PascalCase) …
• Îmi place să folosesc punctele de subliniere pentru a separa părțile unui nume care au semantic scopuri, mai ales dacă caracterul comun al oricărei jumătăți poate fi semnificativ. De exemplu, rutinele Motor1_Start(), Motor2_Start(), Motor1_Stop() și Motor2_Stop() au o relație care ar putea fi mai puțin clară fără subliniere.

Personal , Prefer camelCase, dar în unele fonturi cred că sublinierile sunt mai ușor de citit.

Aș sugera că, dacă trebuie să utilizați prefixe pentru a diferenția seturile de variabile, ar trebui să utilizați o limbă care vă permite să creați spații de nume sau obiecte sau ceva care să dețină acele informații.

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

La fel, dacă trebuie să diferențiați tipurile, de ce să nu folosiți un limbaj care să le permită?

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

Odată ce ați făcut acest lucru și nu folosiți doar numele ca meta-date, atunci nu veți avea suficiente nume lungi încât să contează foarte mult dacă preferați această tastă suplimentară sau nu.

Comentarii

• Unul dintre motivele utilizării camelCase sau underscore_case este astfel încât să nu ' t trebuie să găsesc definiția obiectelor pentru a discerne ce este.

La început, sunt de acord cu dafmetal . Este extrem de important să nu amestecați diferite stiluri de programare. A face acest lucru într-un singur fișier este cel mai rău pe care îl puteți face IMHO. În diferite fișiere, este distractiv, dar nu fatal.

Următorul lucru pe care trebuie să îl faceți este să numiți reguli care sunt populare pentru limba în care scrieți. Codul meu C ++ pentru instnace, va fi arată diferit decât ceva pentru Python, evident (PEP8 este un ghid frumos aici)

Puteți utiliza, de asemenea, convenții de denumire diferite pentru a vă referi la lucruri diferite, atât cât probabil utilizați UPPER_CASE pentru constante (acest lucru se aplică doar anumitor limbi, desigur), puteți utiliza this_style pentru numele variabilelor locale, în timp ce utilizați camelCase pentru variabilele de exemplu / membre. Este posibil să nu fie necesar atunci când aveți lucruri precum self sau this.

Actualizați

Să luăm un caz în care platforma Foo vrăjitoare nu recomandă nicio convenție de numire și este alegerea șefului echipei să aleagă una. Sunteți acel lider de echipă, de ce ați alege camelCase sau de ce underscore_case.

Nu există avantaje pentru unul față de celălalt. Această chestiune este foarte subiectivă și, odată convenită, nu va face diferența. Există întotdeauna aceste războaie legate de aceste lucruri mici. Dar, odată ce v-ați adaptat la oricare dintre ele, discuțiile par a fi cu totul inutile.

Pentru a-l cita pe Alex Martelli despre o chestiune foarte similară:

Sigur, mă obosesc, în Ruby, să tastez „capătul” prostesc la sfârșitul fiecărui bloc (mai degrabă decât doar neindentare) – dar apoi trebuie să evit să scriu „la fel de prost” care: Python necesită la începutul fiecărui bloc, astfel încât să fie aproape o spălare :-). Alte diferențe de sintaxă, cum ar fi „@foo” versus „self.foo”, sau semnificația mai mare a cazului în Ruby vs Python, sunt la fel de irelevante pentru mine.

Alții își bazează, fără îndoială, alegerea limbajelor de programare doar pe astfel de probleme și generează cele mai tari dezbateri – dar pentru mine asta este doar un exemplu al uneia dintre legile lui Parkinson în acțiune ( suma dezbătută asupra unei probleme este invers proporțională cu importanța reală a problemei ).

Sursă

Dacă sunteți liderul echipei, trebuie doar să mergeți cu unul. Întrucât unul nu are avantaje față de celălalt, puteți arunca zaruri sau alegeți ceea ce vă place mai mult.

Am citit în urmă cu câțiva ani că programatorii care nu vorbesc engleza ca primă limbă tind să găsească mai ușor de înțeles cazul de subliniere, dar nu pot găsi referința și nu am nicio idee dacă este adevărat.

Pentru limbaje de programare pe care le-am folosit, cum ar fi Java, Python, C ++, am adoptat un format clar:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Acest lucru îmi permite să discerne imediat cu ce am de-a face. Am constatat că este util să-l mențin și ar trebui să fie ușor de urmărit pentru altcineva care citește codul. Cred că, pe măsură ce alții au menționat coerența, este cel mai important. să fie suficient de simplu de întreținut, oferind în același timp distincții clare între tipurile de nume. Mi-aș putea imagina interface_Names_Are_Like_This și Abstract_Classes_Are_Like_This ca posibile extensii, dar par a fi mai complicat de urmat și poate că nu ar fi o distincție la fel de utilă de făcut.

De asemenea, mi s-a părut util să fiu strict și să denumesc lucruri în PascalCase, cum ar fi un analizor HTML ca HtmlParser în loc de HTMLParser sau HTMLparser. Deoarece cred că este mai ușor să ne amintim de regula strictă și menținem limbile cuvintelor mai clare (din păcate, este nevoie să scriem greșit lucruri precum HTML sau SQL). În mod similar cu camelCase, htmlParserMethod în loc de HTMLParserMethod sau HTMLparserMethod.

UPDATE :

Am găsit o utilizare în extinderea acestor reguli pentru a include variabile private.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

În Java, acest lucru înseamnă că câmpurile private sunt, prin definiție, într-un spațiu de nume diferit de variabilele locale, ceea ce înseamnă că puteți sări 4 câmpuri. Alte formate „Am văzut prefixul cu” m „, dar acele formate folosesc și camelCase pentru numele variabilelor. Acest lucru îmi permite, de asemenea, să fac o distincție între câmpurile care ar trebui accesate numai intern de către clasă (și o face super clar atunci când se întâmplă în afara clasei object._field_x iese în evidență).

Dacă ar fi în sarcina mea, nu aș aplica sau nu sugerez la utilizarea unui anumit stil, deoarece, în calitate de programatori, am putea citi un simbol IfItIsInCamelCase sau in_underscore_space sau chiar în_SomeOtherStyle și să înțelegem ce înseamnă. de lucruri.

Acum, argumentul principal pentru o convenție cred că este că știți dinainte care este formatul unei funcții / nume de variabilă și nu trebuie să-l căutați – este LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Acum, aș contracara acest argument spunând „Obțineți un IDE care acceptă completarea automată a stilului inteligențial!” (totuși nu este întotdeauna posibil).

La sfârșit, totuși, nu contează cu adevărat ce stil folosiți, pentru că compilatorului / interpretului nu îi pasă cu adevărat. Ceea ce este important este că numele este util:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Trei stiluri diferite, dar știi exact ce face fiecare.

Comentarii

• Vă rog să diferim, aspectul sursei este important. Vedeți teoria divizilor sparte " Programatorul pragmatic " ' Convenția de denumire diferită înrăutățește aspectul. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Deși sunt de acord cu ' fereastră spartă ' idee, nu cred că ' nu cred că capitalizarea simbolurilor constituie o ' fereastră spartă '. Codul prezentat în mod aleatoriu este cu siguranță și proiectul meu actual are cu siguranță o mulțime de lucruri pe care încerc să le ordonez ori de câte ori pot.
• Sunt de acord. Îi pot citi pe toți la fel de bine. Nu contează '. Pur și simplu folosesc orice folosește fișierul, apoi orice propune limba (python) și apoi orice simt că proiectul va fi cel mai bine servit. (Obișnuiam să programez în gwbasic și toate erau majuscule – vremurile bune!)

Poate părea o prostie, dar nu îmi plac subliniile, deoarece sublinierea este subțire și se ascunde în text cu mai multe linii și mi-e dor. De asemenea, în unele (multe) editoare de text și / sau medii de dezvoltare, când faceți dublu clic un nume de jeton pentru a-l evidenția astfel încât să îl copiați sau să-l trageți și să-l lăsați, sistemul nu va evidenția întregul jeton, ci doar o porțiune a jetonului, între punctele de subliniere adiacente. Asta mă înnebunește.

Am tendința de a prefera camelCase din motivul prostesc că fac cea mai mare parte a dezvoltării mele în Eclipse (Pentru Java, PHP și JavaScript) și când Ctrl + ← sau Ctrl + → prin cuvinte, se oprește de fapt la limitele camelCase.

Adică: myIntVariable ar fi tratat de Eclipse ca 3 cuvinte când Ct rl + ←   → ” Prin asta.

Știu că este o ciudățenie ciudată, dar prefer să pot edita cuvintele de mijloc într-un nume camelCase.