Utilisez toujours les mêmes conventions de codage pour tout votre JavaScript projets.
Les conventions de codage sont des directives de style pour la programmation. Ils couvrent généralement :
Règles de dénomination et de déclaration des variables et des fonctions.
Règles d'utilisation des espaces blancs, de l'indentation et des commentaires.
Pratiques et principes de programmation.
Conventions de codage qualité garantie :
Améliorer la lisibilité du code
Facilitez la maintenance du code
Les conventions de codage peuvent être des règles documentées que les équipes doivent suivre, ou simplement être votre pratique de codage individuelle.
Cette page décrit les conventions générales du code JavaScript utilisées par W3Schools.
Vous devriez également lire le chapitre suivant « Meilleures pratiques » et apprendre à éviter les pièges du codage.
Chez W3schools, nous utilisons camelCase pour les noms d'identifiants (variables et fonctions).
Tous les noms commencent par une lettre.
Au bas de cette page, vous trouverez une discussion plus large sur la dénomination règles.
firstName = "John";
lastName = "Doe";
price = 19.90;
tax = 0.20;
fullPrice = price + (price * tax);
Mettez toujours des espaces autour des opérateurs (=+ - */), et après les virgules :
let x = y + z;
const myArray = ["Volvo", "Saab",
"Fiat"];
Utilisez toujours 2 espaces pour l'indentation des blocs de code :
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
N'utilisez pas d'onglets (tabulateurs) pour l'indentation. Différents éditeurs interprètent les onglets différemment.
Règles générales pour les déclarations simples :
Terminez toujours une instruction simple par un point-virgule.
const cars = ["Volvo", "Saab",
"Fiat"];
const person = {
firstName: "John",
lastName: "Doe",
age: 50,
eyeColor:
"blue"
};
Règles générales pour les instructions complexes (composées) :
Placez le support d'ouverture à la fin de la première ligne.
Utilisez un espace avant le support d’ouverture.
Placez le crochet fermant sur une nouvelle ligne, sans espaces de début.
Ne terminez pas une instruction complexe par un point-virgule.
function toCelsius(fahrenheit) {
return (5 / 9) * (fahrenheit - 32);
}
for (let i = 0; i < 5; i++) {
x += i;
}
if (time < 20) {
greeting = "Good day";
} else {
greeting = "Good evening";
}
Règles générales pour les définitions d'objets :
Placez le crochet ouvrant sur la même ligne que le nom de l'objet.
Utilisez deux points 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.
N'ajoutez pas de virgule après la dernière paire propriété-valeur.
Placez le crochet fermant sur une nouvelle ligne, sans espaces principaux.
Terminez toujours une définition d'objet par un point-virgule.
Les objets courts peuvent être écrits compressés, sur une seule ligne, en utilisant uniquement des espaces entre les propriétés, comme ceci :
Pour plus de lisibilité, évitez les lignes de plus de 80 personnages.
Si une instruction JavaScript ne tient pas sur une seule ligne, le meilleur endroit pour la rompre c'est après un opérateur ou une virgule.
document.getElementById("demo").innerHTML =
"Hello Dolly.";
Essayez-le vous-même →
<!DOCTYPE html>
<html>
<body>
<h2>My Web Page</h2>
<p>The best place to break a code line is after an operator or a comma.</p>
<p id="demo"></p>
<script>
document.getElementById("demo").innerHTML =
"Hello Dolly.";
</script>
</body>
</html>
Utilisez toujours la même convention de dénomination pour tout votre code. Par exemple:
Noms de variables et de fonctions écrits sous la forme camelCase
Variables globales écrites en MAJUSCULES (Nous ne le faisons pas, mais c'est assez fréquent)
Constantes (comme PI) écrites en MAJUSCULES
Si vous utilisez hyp-hens, camelCase ou under_scores dans les noms de variables ?
C’est une question dont les programmeurs discutent souvent. La réponse dépend de qui vous demander:
Traits d'union en HTML et CSS :
Les attributs HTML5 peuvent commencer par data- (data-quantité, data-price).
CSS utilise des traits d'union dans les noms de propriétés (taille de police).
Les traits d’union peuvent être confondus avec des tentatives de soustraction. Les traits d'union ne sont pas autorisés dans les noms JavaScript.
Soulignements :
De nombreux programmeurs préfèrent utiliser des traits de soulignement (date_of_birth), notamment en SQL. bases de données.
Les traits de soulignement sont souvent utilisés dans la documentation PHP.
PascalCase :
PascalCase est souvent préféré par les programmeurs C.
camelCase :
camelCase est utilisé par JavaScript lui-même, par jQuery et d'autres JavaScript bibliothèques.
Ne commencez pas les noms par le signe $. Cela vous mettra en conflit avec de nombreux noms de bibliothèques JavaScript.
Utilisez une syntaxe simple pour charger des scripts externes (l'attribut type n'est pas nécessaire):
<script src="myscript.js"></script>
L'utilisation de styles HTML « désordonnés » peut entraîner des erreurs JavaScript.
Ces deux instructions JavaScript produiront des résultats différents :
const obj = getElementById("Demo")
const obj = getElementById("demo")
Si possible, utilisez la même convention de dénomination (que JavaScript) en HTML.
Consultez le guide de style HTML.
Les fichiers HTML doivent avoir une extension .html (.htm est autorisé). <p>Les fichiers CSS doivent avoir une extension .css.
Les fichiers JavaScript doivent avoir une extension .js.
La plupart des serveurs Web (Apache, Unix) sont sensibles à la casse concernant les noms de fichiers :
london.jpg n’est pas accessible en tant que London.jpg.
Les autres serveurs Web (Microsoft, IIS) ne sont pas sensibles à la casse :
london.jpg est accessible sous London.jpg ou london.jpg.
Si vous utilisez un mélange de majuscules et de minuscules, vous devez être extrêmement cohérent.
Si vous passez d'un serveur insensible à la casse à un serveur sensible à la casse, même petit des erreurs peuvent détruire votre site Web.
Pour éviter ces problèmes, utilisez toujours des noms de fichiers en minuscules (si possible).
Les conventions de codage ne sont pas utilisées par les ordinateurs. La plupart des règles ont peu d'impact sur l'exécution des programmes.
L'indentation et les espaces supplémentaires ne sont pas significatifs dans les petits scripts.
Pour le code en développement, la lisibilité est à privilégier. Production plus importante les scripts doivent être minimisés.