Share
Mai ales atunci când începem prima dată cu diferite limbi de dezvoltare web, se poate dovedi a fi o sarcină dificilă de a învăța toate convențiile de numire diferite de la limbă la limbă. Acest lucru poate fi și mai confuz când dezvoltatorii nu sunt de acord cu ceea ce este luat în considerare cea mai buna practica. Pentru a facilita tranziția pentru începători, această listă va descrie câteva din convențiile mai comune.
Când întâlniți o variabilă sau o metodă care este procedată de un _, nu există magie voodoo care să fie efectuată în spatele scenei. Este pur și simplu o convenție de numire care reamintește dezvoltatorului că variabila / proprietatea / metoda este fie privat sau protejat, și nu pot fi accesate din afara clasei.
// Această variabilă nu este disponibilă în afara clasei private $ _someVariable; clasa MyClass // Această metodă este disponibilă doar din cadrul acestei clase sau din orice altceva care o moștenesc. funcția protejată __behindTheScenesMethod ()
Rețineți că, în codul de mai sus, sublinierea nu este ceea ce mărci variabila sau metoda privat; privat / protejate cuvântul cheie face asta. Sublinierea este doar o reamintire timp de șase luni în jos pe drum!
var Persoană = (funcție () var _trueAge = 50, _trueWeight = 140; întoarcere vârstă: _trueAge - 15, greutate: _trueWeight - 30;); Personaj; // 35 Person.weight; // 110 Person._trueAge; // undefined (cauza este privată, yo)
Prin a face Persoană egal cu, nu a funcţie, dar întoarcerea obiect, putem crea variabile private. Din nou, prefixul de subliniere ne amintește de acest lucru.
A constant este o variabilă cu o valoare statică, care nu se va schimba. De exemplu, dacă proiectul dvs. a impus necesitatea multiplicării unei valori de către impozitul de stat, puteți să atribuiți această rată, $ .0825 la a constant. Cu toate acestea, nu toate limbile au aceste tipuri de variabile încorporate. Ca atare, este o bună practică să folosiți toate literele majuscule pentru a vă reaminti că lucrați cu constant. Aceasta este o convenție comună în lumea JavaScript, și se utilizează obiectele sale native, cum ar fi MATH.PI.
var TAXRATE = .0825;
Accentsconagua
defini ("TAXRATE", .0825); Sigur, într-un anumit moment, ați întâlnit o variabilă care a urmat o singură literă, cum ar fi "S" sau "I".
$ sName = 'Căpitanul Jack Sparrow';
Acest lucru este denumit Notația maghiară, și a căzut din favoare în ultimii ani, deși este totuși o convenție folosită de multe companii.
Notația maghiară este o convenție de numire care îi amintește dezvoltatorului despre
tipa variabilei cu care lucrează:sTring,eunteger, etc.
În special în lumea JavaScript, această practică este încruntată, datorită faptului că este un limbaj slab tipărit. Un limbaj scris în mod liber este unul care nu vă cere să declarați tipul de date al unei variabile. De ce este semnificativ? Ce se întâmplă dacă, folosind convenția de notare de mai sus, am declarat un șir cu "S" prefix, dar mai târziu a schimbat variabila la un număr întreg? În acel moment, această formă de notație ar fi de fapt împotriva noastră, nu pentru noi.
var sName = "Comandantul locotenent Geordi La Forge"; typeof (sName); // șir ... sName = undefined; typeof (sName) // undefined
Utilizatorii jQuery: înainte de a vă pasi pe piedestalul dvs. și pentru a vă lăuda pentru că nu utilizați această formă de notație, întrebați-vă dacă prefixați variabilele - înfășurate în obiectul jQuery - cu un simbol de dolar? Dacă este așa, este o formă de notație maghiară. Este un simbol prefixat la numele unei variabile care servește exclusiv scopului de a vă informa despre tipul sau calitățile variabilei.
// Simbolul dolarului îmi amintește că această variabilă // are acces la diferite metode ale jQuery. var $ container = $ ('container #'); Asta depinde în întregime de tine. Chiar și mulți membri ai echipei jQuery folosesc metoda prefixului dolarului. În cele din urmă, dacă funcționează pentru tine, asta contează. Personal, de acum un an, nu mai folosesc prefixul simbolului dolar - dar numai pentru că mi-am dat seama că nu era necesar pentru mine. Fă-ți mintea pe asta.
Cum rămâne cu acele nume "variabile", care marchează prima literă a numelui?
$ răspuns = $ SomeClass-> doSomething ();
În codul de mai sus, $ SomeClass este capitalizată deoarece este a clasă și nu a variabil Nume. Din nou, aceasta este o convenție de numire pe care majoritatea dezvoltatorilor o folosesc. Când se întoarce la codul un an mai târziu, este mic bec care le informează că lucrează cu o clasă care are obiecte și metode disponibile.
// Observați capitalul M în numele clasei. clasa $ MyClass function __construct ()
În JavaScript, nu avem clasăes; dar noi avem constructor funcții.
var Jeff = persoană nouă ();
Motivul pentru care capitalizăm numele constructorului (Persoană) se datorează faptului că se poate dovedi ușor de uitat uneori nou cuvinte cheie. În aceste condiții, JavaScript nu va arunca avertismente și poate fi un coșmar pentru a detecta defecțiunea. Capitalizarea este o alertă utilă pentru dezvoltator, atunci când se depanează. Douglas Crockford este un mare avocat al acestei convenții.
Alternativ, dacă doriți să vă protejați de uitarea dvs. de sine viitoare, puteți să vă asigurați că constructorul este, de fapt, corect, înainte de a continua.
funcția Persoană (nume) // Dacă noul cuvânt cheie este absent, constructorul va fi fereastra. // În acest caz, compensați și returnați o nouă instanță dacă (this.constructor! == Person) returnează o nouă Persoană (nume); this.name = nume; // În mod intenționat ați uitat cuvântul cheie "nou" var Joey = Persoană ("Joey"); Joey.name; // Joey De ce variabilele utilizează un model de camelCase, în timp ce altele folosesc un subliniere pentru a separa cuvintele? Care este metoda corectă? Răspunsul este că nu există corect de utilizare. Depinde în întregime de limbajul și / sau de convențiile de codare ale companiei. Ambele sunt perfect acceptabile.
/ / camelCase var preacherOfSockChanging = 'Locotenent Dan'; // under_score var preacher_of_sock_changing = "Locotenent Dan";
Totuși, cu tot ceea ce sa spus, este o practică bună - când aveți opțiunea - să urmați convențiile comune ale limbii pe care o utilizați. De exemplu, marea majoritate a dezvoltatorilor JavaScript folosesc sintaxa camelCase, în timp ce alte limbi, cum ar fi PHP, tind să preferă utilizarea sublinierii. Deși, din nou, acest lucru nu este pus în piatră. Cadrul Zend pledează pentru camelCasing ca pe o bună practică.
Mai important decât ceea ce folosiți este să vă asigurați că vă rămâneți la el!
În special atunci când lucrați la o echipă, este esențial să adoptați structura de directoare potrivită ca dezvoltatorii dvs. colegi. Dar, cel puțin, cu siguranță nu renunțați la toate foile de stil și scripturi în rădăcina proiectului dvs., fără nici o organizație. Mulți dezvoltatori preferă să plaseze toate imaginile, scripturile și foile de stil într-un părinte bunuri director.
/ Proiect Root / Active / js / min script_min.js script.js / css / min stil_min.css style.css / img img1.jpg index.html otherFile.html
De asemenea, notați convenția de a crea și o min , care conține versiunile miniatură adăugate dinamic ale scripturilor și foile de stil.
Atunci când creăm marcarea, sperăm că este pe larg înțeleasă faptul că idși clasăes alegeți să descrieți tipul de conținut și nu aspectele de prezentare. Ca exemplu:
Justin Bieber este secțiunea mea homeboy.
Justin Bieber este secțiunea mea homeboy.
Justin Bieber este secțiunea mea homeboy.
Cum se face? Ce se întâmplă dacă, la șase luni de drum, decideți să plasați secțiunea de ventilator Justin Bieber în middle-DREAPTĂ și-apoi-un-pic-inferior secțiune? În acel moment, dvs. id va face puțin sens.
Pe măsură ce trecem într-o lume HTML5, ar trebui să vă găsiți utilizând mai puțini identificatori în elementele dvs..
ids sunt mai puțin flexibile și sunt de multe ori inutile.
Antetși Subsols Știi ce miroase? Când lucrați pe un site centrat care necesită mai multe fundaluri care se extind pe întreaga lățime a ferestrei (de obicei pentru antet și subsol), în mod obișnuit trebuie să înfășurați conținutul astfel încât elementul exterior să se extindă, în timp ce elementul interior poate rămâne centrat.
Întrucât aceasta este o chestiune comună, este important să se adopte o convenție comună pentru crearea unei marje necesare.
Decizia dificilă aici este că, presupunând că lucrați cu noile elemente HTML5, trebuie să decideți dacă să plasați subsol element din interior sau din exterior. Este încă în discuție, însă am tendința să simt că este mai mult semantic să plasezi realitatea subsol element pe interior.
divs ar trebui să fie utilizate numai atunci când:
Decideți acum dacă doriți sau nu să permiteți utilizarea comenzilor rapide în codul dvs. Scrierea codului precis / curat este întotdeauna o luptă de lizibilitate față de dimensiune. Din acest motiv, este esențial ca echipele de dezvoltare să urmeze aceleași reguli de codare. Pentru a oferi două exemple rapide:
var nume = 'Joe'; // regular if (nume === 'Jeff') alert ("Eu sunt"); altceva alert ("Nope"); // ternar (nume === 'Jeff')? alertă ("Eu sunt"): alertă ("Nope"); // Nu && Pentru condiționări de mână scurtă? var getTweets = adevărat; // regular if (getTweets) alert ('a le obține acum'); // Logic AND // Partea dreaptă nu va fi rulată, cu excepția cazului în care stânga este "true" getTweets && alert ("Obținerea acestora acum"); Mulți dezvoltatori se vor încrunta asupra folosirii logicii ȘI în acest caz, insistând că limitează lizibilitatea. Acesta este cu siguranță un argument valid, deși, totuși, chiar și bibliotecile populare precum jQuery folosesc în mod greu această metodă.
Pentru a reitera, convențiile specifice pe care le alegeți sunt mult mai puțin importante decât asigurarea că veți rămâne în concordanță cu utilizarea dvs. De fapt, multe echipe de dezvoltare își scriu propriile ghiduri de convenții pentru noii angajați. Vă mulțumim pentru lectură!
