Toujours utiliser les mêmes conventions de codage pour tous vos projets JavaScript.
Conventions de codage JavaScript
Conventions de codage sont des lignes directrices de style pour la programmation. Ils couvrent généralement:
- Nommage et de déclaration des règles pour les variables et les fonctions.
- Règles pour l'utilisation de l'espace blanc, indentation et commentaires.
- Programmation pratiques et principes
Conventions de codage de qualité sécurisé:
- Améliore la lisibilité du code
- Faire la maintenance du code plus facile
conventions de codage peuvent être documentées règles pour les équipes à suivre, ou tout simplement être votre pratique de codage individuel.
Cette page décrit les conventions de code JavaScript généraux utilisés par w3ii.
Vous devriez également lire le chapitre suivant «meilleures pratiques», et apprendre à éviter les pièges de codage.
les noms de variables
Au w3ii nous utilisons camelCase pour les noms d'identificateurs (variables et fonctions).
Tous les noms commencent par une lettre.
Au bas de cette page, vous trouverez une discussion plus large sur les règles de nommage.
firstName = "John";
lastName = "Doe";
price = 19.90;
tax = 0.20;
fullPrice = price + (price * tax);Les espaces autour des opérateurs
Toujours mettre des espaces autour des opérateurs ( = + - * / ) , et après des virgules:
Exemples:
var x = y + z;
var values = ["Volvo", "Saab",
"Fiat"];indentation du code
Toujours utiliser 4 espaces pour l'indentation des blocs de code:
Les fonctions:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
Ne pas utiliser les onglets (tabulatrices) pour l'indentation. Différents éditeurs interprètent différemment les onglets.
Règles Déclaration
Règles générales pour les déclarations simples:
- Toujours terminer une déclaration simple avec un point-virgule.
Exemples:
var values = ["Volvo", "Saab",
"Fiat"];
var person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};Règles générales pour les (composés) états complexes:
- Mettez le support d'ouverture à la fin de la première ligne.
- Utilisez un espace avant le support d'ouverture.
- Mettez le support de fermeture sur une nouvelle ligne, sans espaces.
- Ne pas finir une déclaration complexe avec un point-virgule.
Les fonctions:
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
Boucles:
for (i = 0; i < 5; i++) {
x += i;
}conditionals:
if (time < 20) {
greeting = "Good day";
} else {
greeting = "Good evening";
}Règles d'objet
Règles générales pour les définitions d'objet:
- Placez le support d'ouverture sur la même ligne que le nom de l'objet.
- Utilisez côlon plus un espace entre chaque propriété et sa valeur.
- Utilisez des guillemets autour des valeurs de chaîne, pas autour des valeurs numériques.
- Ne pas ajouter une virgule après la dernière paire property-value.
- Placez le support de fermeture sur une nouvelle ligne, sans espaces.
- Toujours terminer une définition d'objet avec un point-virgule.
Exemple
var person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};objets courts peuvent être écrits compressés, sur une seule ligne, en utilisant uniquement des espaces entre les propriétés, comme ceci:
var person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};Longueur de la ligne <80
Pour plus de lisibilité, éviter les lignes de plus de 80 caractères.
Si une instruction JavaScript ne tient pas sur une seule ligne, le meilleur endroit pour le casser, est après un opérateur ou une virgule.
Conventions de nommage
Toujours utiliser la même convention de dénomination pour tout votre code. Par exemple:
- Les noms de variables et de fonctions écrites comme camelCase
- Les variables globales écrites en MAJUSCULES (Nous ne faisons pas, mais il est assez fréquent)
- Constantes (comme PI) écrits en MAJUSCULES
Si vous utilisez HYP-poules, camelCase ou sous_ligne dans les noms de variables?
Ceci est une question programmeurs discutent souvent. La réponse dépend de qui vous demandez:
Hyphens en HTML et CSS:
HTML5 attributs peuvent commencer avec de données (données-quantité, données-prix).
CSS utilise traits d'union dans la propriété des noms (font-size).
Hyphens peuvent être confondus comme des tentatives de soustraction. Les traits d'union ne sont pas autorisés dans les noms JavaScript.
Insiste:
De nombreux programmeurs préfèrent utiliser soulignement (Date_Naissance), en particulier dans les bases de données SQL.
Soulignement sont souvent utilisés dans la documentation de PHP.
PascalCase:
PascalCase est souvent préféré par les programmeurs C.
affaire de chameau:
camelCase est utilisé par JavaScript lui-même, par jQuery, et d'autres bibliothèques JavaScript.
Ne pas commencer les noms avec un signe $. Il vous mettra en conflit avec de nombreux noms de bibliothèques JavaScript.
Chargement JavaScript HTML
Utilisez une syntaxe simple pour le chargement des scripts externes (l'attribut type est pas nécessaire):
<script src="myscript.js">
Accès à des éléments HTML
Une conséquence de l'utilisation des styles HTML "désordre", peut entraîner des erreurs JavaScript.
Ces deux déclarations JavaScript produiront des résultats différents:
var obj =
getElementById("Demo")
var obj = getElementById("demo")
Si possible, utilisez la même convention de nommage (JavaScript) en HTML.
Visitez le Guide de style HTML .
Extensions de fichier
Les fichiers HTML doivent avoir une extension .html (non .htm).
Les fichiers CSS doivent avoir une extension .css.
Les fichiers JavaScript doivent avoir une extension .js.
Utilisez minuscule des noms de fichiers
La plupart des serveurs web (Apache, Unix) sont sensibles à la casse sur les noms de fichiers:
london.jpg ne peut pas être accessible en tant que London.jpg .
D'autres serveurs web (Microsoft, IIS) ne sont pas sensibles à la casse:
london.jpg est accessible comme London.jpg ou london.jpg .
Si vous utilisez un mélange de majuscules et minuscules, vous devez être extrêmement cohérent.
Si vous passez d'une casse, à un serveur sensible à la casse, même de petites erreurs peuvent briser votre site web.
Pour éviter ces problèmes, utilisez toujours les noms de fichiers de cas inférieurs (si possible).
Performance
conventions de codage ne sont pas utilisés par les ordinateurs. La plupart des règles ont peu d'impact sur l'exécution des programmes.
Indentation et des espaces supplémentaires ne sont pas significatifs dans les petits scripts.
Pour le code dans le développement, la lisibilité doit être préférée. Grandes scripts de production devraient être minified.