Usare sempre le stesse convenzioni di codifica per tutti i vostri progetti JavaScript.
Convenzioni di codifica JavaScript
Convenzioni di codifica sono le linee guida di stile per la programmazione. Di norma, riguardano:
- regole di denominazione e di dichiarazione per variabili e funzioni.
- Regole per l'uso dello spazio bianco, il rientro, e commenti.
- Programmazione pratiche e principi
Coding convenzioni di qualità e sicuro:
- Migliora la leggibilità del codice
- Rendere il codice più facile manutenzione
convenzioni di codifica possono essere documentati regole per le squadre da seguire, o semplicemente essere la vostra pratica codifica individuale.
Questa pagina descrive le convenzioni generali del codice JavaScript utilizzati da w3ii.
Si dovrebbe anche leggere il prossimo capitolo "Best Practices", e imparare a evitare di codifica insidie.
I nomi delle variabili
Al w3ii usiamo camelCase per i nomi di identificatori (variabili e funzioni).
Tutti i nomi iniziano con una lettera.
In fondo a questa pagina, troverete una discussione più ampia su regole di denominazione.
firstName = "John";
lastName = "Doe";
price = 19.90;
tax = 0.20;
fullPrice = price + (price * tax);Spazi intorno Operatori
Mettere sempre gli spazi intorno operatori ( = + - * / ) , e dopo le virgole:
Esempi:
var x = y + z;
var values = ["Volvo", "Saab",
"Fiat"];Codice indentazione
Usare sempre 4 spazi per l'indentazione dei blocchi di codice:
funzioni:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
Non utilizzare schede (tabulazioni) per l'indentazione. Diversi editor interpretano le schede in modo diverso.
Regole Dichiarazione
Regole generali per semplici istruzioni:
- terminare sempre una semplice affermazione con un punto e virgola.
Esempi:
var values = ["Volvo", "Saab",
"Fiat"];
var person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};Regole generali per le dichiarazioni complessi (composti):
- Mettere la staffa apertura all'estremità della prima riga.
- Utilizzare uno spazio prima della parentesi di apertura.
- Mettere la parentesi di chiusura su una nuova linea, senza spazi iniziali.
- Non terminare una dichiarazione complesso con un punto e virgola.
funzioni:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
loops:
for (i = 0; i < 5; i++) {
x += i;
}Condizionali:
if (time < 20) {
greeting = "Good day";
} else {
greeting = "Good evening";
}Regole degli oggetti
Regole generali per definizioni di oggetti:
- Posizionare la parentesi di apertura sulla stessa linea, come il nome dell'oggetto.
- Utilizzare i due punti più uno spazio tra ogni proprietà e il suo valore.
- Usa virgolette intorno ai valori di stringa, non intorno a valori numerici.
- Non aggiungere una virgola dopo l'ultima coppia proprietà-valore.
- Posizionare la staffa di chiusura su una nuova linea, senza spazi iniziali.
- terminare sempre una definizione di un oggetto con un punto e virgola.
Esempio
var person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};oggetti brevi possono essere scritti compressi, su una sola riga, utilizzando gli spazi solo tra proprietà, come questo:
var person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};Lunghezza linea <80
Per facilitare la lettura, evitare le linee più lunghe di 80 caratteri.
Se una dichiarazione JavaScript non si adatta su una sola riga, il posto migliore per romperlo, è dopo un operatore o una virgola.
Convenzioni di denominazione
Usare sempre la stessa convenzione di denominazione per tutto il codice. Per esempio:
- I nomi delle variabili e funzioni scritti come camelCase
- Le variabili globali scritti in maiuscolo (Noi non facciamo, ma è abbastanza comune)
- Costanti (come PI) scritti in maiuscolo
Si dovrebbe utilizzare HYP-galline, camelCase o under_scores nei nomi delle variabili?
Questa è una domanda programmatori spesso discutono. La risposta dipende da chi si chiede:
I trattini in HTML e CSS:
HTML5 attributi può iniziare con data- (data-quantità, dati-prezzo).
CSS utilizza trattini in immobili nomi (font-size).
I trattini possono essere scambiati come tentativi di sottrazione. I trattini non sono consentiti nei nomi JavaScript.
sottolinea:
Molti programmatori preferiscono utilizzare sottolineatura (date_of_birth), in particolare nei database SQL.
Sottolineatura sono spesso utilizzati nella documentazione di PHP.
PascalCase:
PascalCase è spesso preferito dai programmatori C.
camelCase:
camelCase è utilizzato da JavaScript per sé, per jQuery, e altre librerie JavaScript.
Non iniziare i nomi con un segno $. Esso vi metterà in conflitto con molti nomi di libreria JavaScript.
Caricamento JavaScript in HTML
Utilizzare la sintassi semplice per il caricamento di script esterni (l'attributo type non è necessario):
<script src="myscript.js">
Accesso agli elementi HTML
Una conseguenza di utilizzo di stili HTML "disordinato", potrebbe comportare errori JavaScript.
Queste due istruzioni JavaScript produrranno risultati diversi:
var obj =
getElementById("Demo")
var obj = getElementById("demo")
Se possibile, utilizzare la stessa convenzione di denominazione (come JavaScript) in HTML.
estensioni di file
File HTML devono avere una estensione .html (non htm).
File CSS dovrebbero avere una estensione css.
File JavaScript devono avere estensione .js.
Utilizzare minuscola nomi di file
La maggior parte dei server web (Apache, Unix) sono case sensitive sui nomi di file:
london.jpg non è possibile accedere come London.jpg .
Altri web server (Microsoft, IIS) non sono case sensitive:
london.jpg si può accedere come London.jpg o london.jpg .
Se si utilizza un mix di lettere maiuscole e minuscole, bisogna essere estremamente coerente.
Se ci si sposta da un case insensitive, a un server sensibile caso, anche piccoli errori possono rompere il vostro sito web.
Per evitare questi problemi, utilizzare sempre nomi di file minuscolo (se possibile).
Prestazione
convenzioni di codifica non vengono utilizzati dai computer. La maggior parte delle norme hanno poco impatto sulla esecuzione dei programmi.
Rientro e spazi aggiuntivi non sono significativi in piccoli script.
Per il codice in fase di sviluppo, la leggibilità dovrebbe essere preferito. script di produzione più grandi dovrebbero essere minimizzato.