Utilizați întotdeauna aceleași convenții de codificare pentru toate proiectele dvs. JavaScript.
Convenții de codificare JavaScript
Convenții de codificare sunt linii directoare de stil pentru programare. Acestea acoperă în mod obișnuit:
- Reguli de denumire și declarația de variabile și funcții.
- Reguli pentru utilizarea spațiului alb, indentare, și comentarii.
- Programare practici și principii
Convenții de codificare sigure de calitate:
- Îmbunătățește codul de lizibilitate
- Asigurați-vă de întreținere mai ușor de cod
convenții de codificare pot fi documentate reguli pentru echipe să urmeze, sau pur si simplu sa fie practica de codificare individuală.
Această pagină descrie generale convențiile de cod JavaScript utilizate de w3ii.
Ar trebui să citiți , de asemenea , capitolul următor "Best Practices" , și să învețe cum să evite capcanele de codificare.
Nume variabile
La w3ii folosim CamelCase pentru nume de identificare (variables and functions) .
Toate numele începe cu o literă.
În partea de jos a acestei pagini, veți găsi o discuție mai largă despre regulile de denumire.
firstName = "John";
lastName = "Doe";
price = 19.90;
tax = 0.20;
fullPrice = price + (price * tax);A spațiilor din jurul operatorilor
Întotdeauna puneți spații în jurul operatorilor ( = + - * / ) , și după virgulă:
Exemple:
var x = y + z;
var values = ["Volvo", "Saab",
"Fiat"];Cod Indentarea
Utilizați întotdeauna 4 spații pentru indentare de blocuri de cod:
funcţii:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
Nu utilizați file (tabulators) pentru indentare. Diferite editori interpretează în mod diferit file.
Reguli Declarație
Reguli generale pentru declarații simple:
- Întotdeauna se încheie o declarație simplă, cu punct și virgulă.
Exemple:
var values = ["Volvo", "Saab",
"Fiat"];
var person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};Reguli generale pentru complexe (compound) declarații:
- Puneți paranteza de deschidere la sfârșitul primei linii.
- Utilizați un spațiu înainte de paranteza de deschidere.
- Puneți suportul de închidere pe o linie nouă, fără spații de conducere.
- Nu încheiați o declarație complex cu punct și virgulă.
funcţii:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
bucle:
for (i = 0; i < 5; i++) {
x += i;
}Condiționalele:
if (time < 20) {
greeting = "Good day";
} else {
greeting = "Good evening";
}Reguli obiect
Reguli generale pentru definiții de obiect:
- Așezați suportul de deschidere pe aceeași linie ca nume de obiect.
- Utilizați două puncte plus un spațiu între fiecare proprietate și valoarea sa.
- Folosiți ghilimele în jurul valorii de valori string, nu în jurul valorii de valori numerice.
- Nu adăugați o virgulă după ultima pereche de proprietate-valoare.
- Așezați suportul de închidere pe o linie nouă, fără spații de conducere.
- termină întotdeauna o definiție obiect cu punct și virgulă.
Exemplu
var person = {
firstName: "John" ,
lastName: "Doe" ,
age: 50,
eyeColor:
"blue"
};obiecte scurte pot fi scrise comprimat, pe o singură linie, folosind doar spații între proprietăți, cum ar fi aceasta:
var person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};Linia Lungime <80
Pentru lizibilitate, evita liniile mai lungi de 80 de caractere.
Dacă o declarație JavaScript nu se potrivește pe o singură linie, cel mai bun loc pentru a-l rupe, este după un operator sau o virgulă.
Convențiile de denumire
Utilizați întotdeauna aceeași convenție de denumire pentru toate codul. De exemplu:
- Variabile și funcții nume scrise ca CamelCase
- Variabilele globale scrise cu litere mari (Noi nu facem, dar este destul de comună)
- Constantele (like PI) scrise în UPPERCASE
Ar trebui să utilizați Hyp-găini, CamelCase sau under_scores în nume de variabile?
Aceasta este o întrebare de programatori de multe ori discuta. Răspunsul depinde de cine vă întreb:
Cratima in HTML si CSS:
HTML5 atribute pot începe cu a datelor (data-quantity, data-price) de (data-quantity, data-price) .
CSS folosește cratime în proprietate nume (font-size) .
Cratime poate fi confundat cu tentative de scădere. Cratima nu sunt permise în numele JavaScript.
subliniere:
Mulți programatori preferă să utilizeze subliniere (date_of_birth) , în special în bazele de date SQL.
Subliniere sunt adesea folosite în documentația PHP.
PascalCase:
PascalCase este adesea preferat de programatori C.
CamelCase:
CamelCase este utilizat de la sine JavaScript, de jQuery, și alte biblioteci JavaScript.
Nu începe numele cu semnul $. Acesta vă va pune în conflict cu mai multe nume de bibliotecă JavaScript.
Se încarcă JavaScript în HTML
Utilizați sintaxă simplă pentru încărcarea script - uri externe ( de type atribut nu este necesar):
<script src="myscript.js">
Accesarea HTML Elemente
O consecință a utilizării "untidy" stiluri HTML, ar putea avea ca rezultat erori JavaScript.
Aceste două declarații JavaScript va produce rezultate diferite:
var obj =
getElementById("Demo")
var obj = getElementById("demo")
Dacă este posibil, utilizați aceeași convenție de denumire (as JavaScript) în HTML.
Vizitați Ghidul stilistic HTML .
Extensii de fișiere
Fișierele HTML ar trebui să aibă o extensie .html (not .htm ) .
Fișiere CSS ar trebui să aibă o extensie .css.
Fișiere JavaScript ar trebui să aibă o extensie .js.
Utilizați nume de fișiere Minuscule
Cele mai multe servere de web (Apache, Unix) sunt cazuri sensibile cu privire la nume de fișiere:
london.jpg nu pot fi accesate ca London.jpg .
Alte servere de web (Microsoft, IIS) nu sunt sensibile la litere:
london.jpg pot fi accesate ca London.jpg sau london.jpg .
Dacă utilizați o combinație de litere mari și mai mici, trebuie să fie extrem de consistente.
Dacă mutați de la un caz insensibil, la un server de sensibil caz, chiar si mici erori pot rupe site-ul dvs. web.
Pentru a evita aceste probleme, folosiți întotdeauna nume de fișiere cu litere mici (if possible) este (if possible) .
Performanţă
convenții de codificare nu sunt folosite de calculatoare. Cele mai multe norme au un impact redus asupra executării programelor.
Indentare și spații suplimentare nu sunt semnificative în script-uri mici.
Pentru codul în dezvoltare, ar trebui să fie preferată lizibilitate. script-uri de producție mai mari ar trebui să fie minimizate.