Préface:
Le style de codage d'un langage de programmation est très important pour un logiciel de maintenance à long terme, en particulier dans le travail d'équipe. Si une équipe utilise un style de codage unifié et standardisé, il peut améliorer le niveau de collaboration de l'équipe et l'efficacité du travail. Au cœur du guide de style de programmation se trouvent des règles de mise en forme de base qui déterminent comment écrire du code de haut niveau. Ce guide provient du livre "Écriture de JavaScript maintenable", basé sur les "spécifications de codage du langage Java" et les spécifications de programmation JavaScript de Crockford, ainsi que sur l'expérience et les préférences personnelles de Nicbolas. Le but de la rédaction de cet article est d'approfondir votre impression et de faire comprendre plus de gens le style de codage JS et d'améliorer leur qualité de codage. Pour plus d'informations, veuillez lire "Rédaction de JavaScript maintenable".
1.
Le niveau de chaque ligne est composé de 4 espaces, évitant l'indentation à l'aide de l'onglet.
// Bonne méthode d'écriture if (true) {DoSomething ();}2. la longueur de la ligne
Chaque ligne ne doit pas dépasser 80 caractères. Si une ligne dépasse 80 caractères, elle doit être brisée après un opérateur. La ligne suivante doit ajouter deux niveaux d'indentation (8 caractères).
// Bonne méthode d'écriture dosomething (argument1, argument2, aegment3, argument4, argument5); // Méthode d'écriture mauvaise: le dossier de fond (argument1, argument2, aegment3, argument4, argument5);
3. Valeur d'origine
Les cordes doivent toujours utiliser des citations doubles et conserver une ligne, en évitant d'utiliser des barres obliques pour démarrer une ligne dans la chaîne.
Les nombres doivent utiliser des entiers décimaux et les algorithmes scientifiques représentent des entiers, des entiers hexadécimaux ou des décimales à virgule flottante décimales. Au moins un nombre doit être conservé avant et après la décimale. Évitez d'utiliser des quantités directes octales.
La valeur spéciale NULL doit être évitée, sauf dans les cas suivants.
• Utilisé pour initialiser une variable, qui peut se voir attribuer une valeur à un objet.
• Utilisé pour comparer avec une variable initialisée, qui peut être ou n'est pas un objet.
• Lorsque le paramètre d'une fonction devrait être un objet, il est passé en tant que paramètre.
• Lorsque la valeur de retour de la fonction devrait être un objet, elle est évanouie en tant que valeur de retour.
Évitez d'utiliser des valeurs spéciales non définies. Pour déterminer si une variable est définie, le type d'opérateur doit être utilisé.
4. Espacement de l'opérateur
Un espace doit être utilisé avant et après le budget binaire pour maintenir l'expression soignée. Les opérateurs comprennent les opérateurs d'affectation et les opérateurs logiques.
// bonne écriture pour (var i = 0; i <count; i ++) {processus (i);} // mauvaise écriture: espace perdu pour (var i = 0; i <count; i ++) {process (i);}5. Espacement des supports
Lorsque vous utilisez des supports, il ne devrait pas y avoir d'espace immédiatement après le support de gauche et immédiatement avant le support de fermeture.
// bonne écriture pour (var i = 0; i <count; i ++) {process (i);} // mauvaise écriture: il y a des espaces supplémentaires des deux côtés du paramètre pour (var i = 0; i <count; i ++) {process (i);}6. Mesure directe des objets
La quantité directe de l'objet doit avoir le format suivant.
• Les accolades de départ gauche doivent être conservées sur la même ligne que l'expression.
• La valeur du nom de chaque attribut doit être maintenue en retrait et le premier attribut doit être une nouvelle ligne après l'attelle bouclée gauche.
• La valeur du nom de chaque attribut doit être utilisée sans devis, suivie d'un côlon (avant l'espace), suivie d'une valeur.
• Si la valeur d'attribut est un type de fonction, le corps de fonction doit démarrer une nouvelle ligne sous le nom d'attribut et une ligne vierge doit être conservée avant et après.
• Les lignes vierges peuvent être insérées avant et après un ensemble de propriétés connexes pour améliorer la lisibilité du code.
• La fin de la fin de la droite devrait occuper une ligne exclusivement.
// bonne méthode d'écriture var objet = {key1: value1, key2: value2, func: function () {// dosomething}, key3: value3}; // mauvaise méthode d'écriture: inapproprié indentation var objet = {key1: value1, key2: value2}; // mauvaise méthode d'écriture: absence de lignes vide autour de la fonction var objet = {key1: value1, key2: Value2, func autour de la fonction Var Object = {key1: value1, key2: Value2, Func autour de la fonction Var Object = {Key1: Value1, Key2: // dosomething}, key3: value3};Lorsque l'objet littéral est utilisé comme paramètre de fonction, si la valeur est une variable, les accolades de démarrage doivent être sur la même ligne que le nom de fonction. Toutes les autres règles précédemment répertoriées s'appliquent également.
// bonne méthode d'écriture dosomething ({key1: value1, key2: value2}); // Méthode d'écriture mauvaise: tous les codes dosomething ({key1: value1, key2: value2});7. Commentaires
L'utilisation de commentaires concis et clairs peut aider les autres à comprendre votre code. Les commentaires doivent être utilisés dans les situations suivantes.
• Le code est obscur.
• Codes qui peuvent être confondus avec une erreur.
• Code nécessaire du navigateur nécessaire mais pas évident.
• Pour les objets, les méthodes ou les propriétés, il est nécessaire de générer des documents (en utilisant des commentaires de documents appropriés).
Commentaires de ligne unique
Les commentaires à une seule ligne doivent être utilisés pour illustrer une ligne de code ou un ensemble de codes connexes. Il peut y avoir trois façons d'utiliser des commentaires à une seule ligne.
• Commentaires exclusifs pour expliquer la ligne de code suivante.
• Commentaires à la fin de la ligne de code pour expliquer le code qui lui est saisi.
• Plusieurs lignes pour commenter un bloc de code.
// Bonne écriture si (condition) {// Si le code est exécuté ici, cela signifie que tous les chèques de sécurité ont été passés;} // Bad Writing: Il n'y a pas de ligne vierge avant le commentaire si (condition) {// Si le code est exécuté ici, cela signifie que toutes les vérifications de sécurité ont été transmises;} // Mauvaise rédaction: une intention incorrecte si tout le code est réalisé; Écriture: les commentaires multi-lignes doivent être utilisés // Ce morceau de code est utilisé pour ** Jugement // Alors si (condition) {// Si le code est exécuté ici, cela signifie que tous les chèques de sécurité ont été passés;} // bonne écriture: lors de commentaire à la fin de la ligne, un espace doit être conservé entre la fin du code et le commentaire si (la condition) {// si le code est exécuté ici, cela signifie que tout ce que les vérifications de la sécurité ont été réalisées; // Exécuter la fonction **} // Mauvaise écriture: il n'y a pas assez d'espaces entre le code et le commentaire si (condition) {// si le code est exécuté ici, cela signifie que tous les chèques de sécurité ont été adoptés (); // Exécuter la fonction **} // bonne écriture: lors de la commentaire d'un bloc de code, vous devez contacter pour utiliser un commentaire en ligne unique et les commentaires multi-lignes ne doivent pas être utilisés dans ce cas. // if (condition) {// autorisé (); // exécuter ** fonction //}Commentaires multi-lignes
Les commentaires en plusieurs lignes doivent être utilisés lorsque le code a besoin de plus de texte pour interpréter. Chaque commentaire en plusieurs lignes a au moins trois lignes comme suit:
1. La première ligne ne comprend que le début / * commentaire. Il ne devrait y avoir aucun autre texte dans cette ligne.
2. Les lignes suivantes commencent par * et restent à gauche. Ceux-ci peuvent être décrits en mots.
3. La dernière ligne commence par * / et reste aligné avec la ligne précédente. Il ne devrait y avoir aucun autre texte.
La première ligne d'un commentaire en plusieurs lignes devrait maintenir le même niveau d'indentation qu'il décrit le code. Chaque ligne suivante doit avoir le même niveau d'indentation et un espace attaché (pour garder correctement les * caractères alignés). Une ligne vierge doit être réservée avant chaque code multi-lignes.
// Bonne méthode d'écriture, if (condition) {/ * * Si le code est exécuté ici *, cela signifie que toutes les détections de sécurité ont été transmises * / autorisés ();}Déclaration de commentaires
Les commentaires peuvent parfois être utilisés pour déclarer des informations supplémentaires à un morceau de code. Le format de ces déclarations commence par un seul mot et est immédiatement suivi d'un côlon. Les déclarations qui peuvent être utilisées sont les suivantes.
TODO: Le code de description n'est pas encore terminé. Cela devrait inclure ce que vous voulez faire ensuite.
Hack: Il montre que l'implémentation du code a pris un raccourci. Devrait inclure des raisons pour lesquelles des hacks sont utilisés. Cela peut également indiquer qu'il peut y avoir une meilleure solution au problème.
XXX: Expliquez que le code est problématique et doit être corrigé dès que possible.
FIXME: Expliquez que le code est problématique et doit être corrigé dès que possible. Il est un peu deuxième à xxx.
Revue: les codes d'instruction doivent être examinés dans toutes les modifications possibles.
Ces déclarations peuvent être utilisées dans un ou plusieurs commentaires et doivent suivre les mêmes règles de formatage que le type de commentaire général.
8. Nommer
Les variables et les fonctions doivent être prudentes lors de leur nom. La dénomination doit être limitée aux caractères alphabétiques numériques et les soulignements (_) peuvent être utilisés dans certains cas. Il est préférable de ne pas utiliser le signe dollar ($) ou le bar (/) dans toute dénomination.
La dénomination variable doit être au format de dénomination de chameau, avec la première lettre en minuscules et la première lettre de chaque mot majuscule. Le premier mot du nom de la variable doit être un nom (pas un verbe) pour éviter la confusion avec la même fonction. N'utilisez pas de soulignements dans les noms de variables.
// Bonne méthode d'écriture var compteNumber = "test001"; // Bad Writing Method: Démarrez avec des lettres majuscules var compteNumber = "Test001"; // Méthode d'écriture mauvaise: Démarrez par verb var getAccountNumber = "test001"; // Méthode d'écriture mauvaise: utilisez le sous-ore Var account_number = "test001";
Les noms de fonction doivent également être au format de dénomination de camel. Le premier mot du nom de la fonction doit être un verbe (pas un nom) pour éviter la confusion avec la même variable. Il est préférable de ne pas utiliser de soulignements dans les noms de fonction.
// Bonne méthode d'écriture Fonction Dosomething () {// code} // Méthode d'écriture mauvaise: fonction DoSomething () {// code} // Méthode d'écriture mauvaise: fonction quelque chose () {// code} // Méthode d'écriture de mauvais: utilisation de la fonction de sous-ore Do_Something () {// Code}Le constructeur - une fonction qui crée un nouvel objet via le nouvel opérateur - doit également être nommé au format Camel et le premier caractère est capitalisé. Le nom du constructeur doit commencer par un non-verbe, car nouveau représente le fonctionnement de la création d'une instance d'un objet.
// Bonne méthode d'écriture function myObject () {// code} // Méthode d'écriture mauvaise: fonction myObject () au début des lettres minuscules {// code} // Méthode d'écriture de mauvaise rédaction: Utilisez la fonction de sous-oreLe nom des constantes (variables dont les valeurs ne sont pas modifiées) doit être toutes les lettres majuscules, séparées par un seul soulignement entre différents mots.
// Bonne méthode d'écriture var total_count = 10; // Méthode d'écriture de mauvaise: Camel Form var totalCount = 10; // Méthode d'écriture méchante: MIXT FORM VAR TOTAL_COUNT = 10;
Les attributs des objets sont les mêmes que ceux des variables. Les méthodes des objets sont les mêmes que celles des fonctions. Si la propriété ou la méthode est privée, un soulignement doit être ajouté avant lui.
// bonne méthode d'écriture var objet = {_count: 10,4 _getCount: function () {return this._count; }}9. Déclaration de variables et de fonctions
Déclaration variable
Toutes les variables doivent être définies à l'avance avant utilisation. Les définitions variables doivent être placées au début de la fonction, en utilisant une expression VAR une variable par ligne. À l'exception de la première ligne, toutes les lignes doivent être en retrait d'une couche de plus afin que les noms de variable puissent être alignés verticalement. Les définitions variables doivent être initialisées et les opérateurs d'affectation doivent maintenir une indentation cohérente. La variable initialisée doit être avant que la variable ne soit initialisée.
// bonne méthode d'écriture var count = 10, name = "jeri", fondée = false, vide;
Déclaration de fonction
Les fonctions doivent être définies à l'avance avant utilisation. Une fonction qui n'est pas une méthode (c'est-à-dire aucun attribut en tant qu'objet) ne doit utiliser le format défini par la fonction (pas le format d'expression de fonction et de constructeur de fonction). Il ne devrait pas y avoir d'espace entre le nom de la fonction et les parenthèses de démarrage. Un espace doit être laissé entre les supports de fin et les supports bouclés à droite. Les accolades bouclées à droite doivent rester sur la même ligne que le mot clé de la fonction. Il ne devrait pas y avoir d'espace entre les supports de départ et de fin. Un espace doit être laissé après une virgule entre les noms de paramètres. Le corps de fonction doit rester en retrait au premier niveau.
// Bonne Fonction de méthode d'écriture extérieure () {var count = 10, name = "Jeri", Found = false, vide; fonction inner () {// code} // code qui appelle inner ()}Les fonctions anonymes peuvent être attribuées comme méthodes aux objets ou comme paramètres à d'autres fonctions. Il ne devrait pas y avoir d'espace entre le mot clé de la fonction et le support de démarrage.
// bonne méthode d'écriture objet.Method = function () {// code}; // Méthode d'écriture mauvaise: objet spatial incorrect.Method = function () {// code};La fonction appelée immédiatement doit être enveloppée dans les parenthèses de jardin sur la couche externe de l'appel de fonction.
// bonne méthode var value = (function () {// Function Body return {message: "hi"}} ());Mode strict
Le mode strict ne doit être utilisé que dans les fonctions et ne doit pas être utilisé à l'échelle mondiale.
// Bad Writing Method: Utilisez le mode strict "Utilisez Strict"; fonction dosomething () {// code} // bonne méthode d'écriture function dosomething () {"use strict"; // Code}10. Opérateurs
Affectation
Lorsque vous attribuez une valeur à une variable, si le côté droit est une expression contenant une instruction de comparaison, elle doit être enveloppée entre parenthèses.
// bonne écriture var flag = (i <count); // mauvaise écriture: parenthèses manquants var flag = i <count;
Opérateur de signes égal
Use === (strictement égal) et! == (strictement inégal) au lieu de == (égal) et! = (Inégal) pour éviter les erreurs de conversion de type faible.
// bon écriture var identique = (a === b); // bon écriture var identique = (a == b);
Triple opérateur
L'opérateur ternaire ne doit être utilisé que dans les instructions d'attribution conditionnelle et ne doit pas être utilisé comme substitut des instructions IF.
// Bonne méthode d'écriture var valeur = condition? Value1: Value2; // Bad Writing Method: Aucune affectation, si l'expression doit être utilisée? DoSomething (): Dosomethingelse;
11. Déclaration
Déclaration simple
Chaque ligne ne contient qu'une seule instruction au plus. Toutes les déclarations simples devraient se terminer par un point-virgule (;).
// bon nombre de méthodes d'écriture ++; a = b; // Méthode d'écriture mauvaise: plusieurs expressions sont écrites en un nombre de lignes ++; a = b;
Déclaration de retour
Les instructions de retour ne doivent pas être enveloppées entre parenthèses lors du retour d'une valeur, sauf si dans certains cas, cela peut rendre la valeur de retour plus facile à comprendre. Par exemple:
return; return collection.size (); return (size> 0? size :fault-size);
Déclarations composées
Une instruction composée est une liste d'instructions enfermées en accolades.
• L'énoncé ci-joint doit être en retrait d'un niveau de plus que la déclaration composée.
• Les accolades de début doivent être à la fin de la ligne où se trouve l'instruction composée; Les accolades de fin doivent occuper une ligne et rester en retrait de la même manière que le début de la déclaration composée.
• Lorsqu'une instruction fait partie d'une structure de contrôle, comme si ou pour les instructions, toutes les instructions doivent être enfermées en accolades, y compris une seule instruction. Cette convention nous permet d'ajouter plus facilement des déclarations sans se soucier d'oublier d'ajouter des supports et de provoquer des bogues.
• Les mots clés pour une déclaration comme IF devraient commencer, suivis d'un espace, et les accolades de démarrage doivent être suivies d'un espace.
Si déclaration
L'énoncé IF doit être dans le format suivant.
if (condition) {instructions} if (condition) {instructions} else {instructions} if (condition) {instructions} else if (condition) {instructions} else {instructions}Il n'est jamais autorisé à omettre des accolades bouclées dans les instructions IF.
// bonne écriture if (condition) {DoSomething ();} // Bad Writing: Spaces inappropriés if (condition) {DoSomething ();} // Bad Writing: Tout le code est sur une ligne if (condition) {DoSomething (); } // Mauvaise écriture: tout le code est sur une seule ligne et il n'y a pas de montagnes bouclées si (condition) DoSomething ();pour déclaration
Pour les instructions de type doit être dans le format suivant.
pour (initialisation; condition; mise à jour) {instructions} pour (variable dans l'objet) {instructions}La partie d'initialisation de l'instruction FOR ne doit pas avoir de déclarations variables.
// bonne méthode var i, len; for (i = 0, len = 0; i <len; i ++) {// code} // bad writing: dislare variable for (var i = 0, len = 0; i <len; i ++) {// code} // bad writing: disclare variable for (var prop in object) {code}Lorsque vous utilisez la déclaration for-in, n'oubliez pas d'utiliser HasownProperty () pour une double vérification pour filtrer les membres de l'objet.
lors de la déclaration
Les déclarations de la classe WHNE doivent être dans le format suivant.
while (condition) {instructions}faire une déclaration
Les déclarations de la classe DO doivent être dans le format suivant.
faire {instructions} while (condition);Déclaration de commutation
Les instructions de la classe Switch doivent être dans le format suivant.
switch (expression) {case expression: instructions default: instructions}Le premier cas sous l'interrupteur doit être maintenu en retrait. Chaque cas sauf le premier, y compris par défaut, doit conserver une ligne vide avant lui.
Chaque ensemble d'instructions (sauf par défaut) doit se terminer par la pause, le retour, le lancer ou être sauté avec une ligne de commentaires.
// bon commutateur de méthode d'écriture (valeur) {cas 1: / * tombe à travers * / cas 2: DoSomething (); casser; Cas 3: Retour True; par défaut: lancez une nouvelle erreur ("une erreur");}Si une instruction Switch ne contient pas de cas par défaut, une ligne de commentaires doit être remplacée.
// bon commutateur de méthode d'écriture (valeur) {cas 1: / * tombe à travers * / cas 2: DoSomething (); casser; Cas 3: Retour True; par défaut: // pas de défaut}Énoncé d'essai
Les instructions de la classe TRY doivent être formatées comme suit.
essayez {instructions} catch (variable) {instructions} try {instructions} catch (variable) {instructions} enfin {instructions}12. Laisser blanc
L'ajout de lignes de code vides entre le code lié à la logique peut améliorer la lisibilité du code.
Deux lignes vides sont limitées à l'utilisation dans les situations suivantes:
• Entre différents fichiers de code source.
• Entre les définitions de classe et d'interface.
Les lignes vides à ligne unique ne sont disponibles que dans les cas suivants.
• Entre les méthodes.
• Entre la variable locale dans la méthode et la première instruction de ligne.
• Avant les commentaires multiples ou uniques.
• Les blocs de code logiques dans la méthode sont utilisés pour améliorer la lisibilité du code.
Les espaces doivent être utilisés dans les situations suivantes.
• Le cas où les mots clés sont suivis des supports doivent être séparés par des espaces.
• Un espace doit être laissé après une virgule dans la liste des paramètres.
• Les opérandes de tous les opérateurs binaires à l'exception des points (.) Doivent être séparés par des espaces. Les opérandes des opérateurs de monologues ne doivent pas être séparés par des blancs, comme un signe moins unaire, l'incrément (++), la décrémentation (-).
• Les expressions de la déclaration FOR doivent être séparées par des espaces.
13. Ce qui doit être évité
• Ne créez pas de nouveaux objets à l'aide de types de wrapper originaux comme String.
• Évitez d'utiliser EVAL ().
• Évitez d'utiliser avec des instructions. Cette déclaration n'existe plus en mode strict et peut également être supprimée dans les futures normes ECMAScript.
Écrit à la fin
Les guides ci-dessus ne sont pas entièrement suivis pendant le processus de développement. Nous ne pouvons en dessiner que pour améliorer notre style de codage et rendre notre code lisible et maintenu. En ce qui concerne le style de codage, chaque équipe a ses propres caractéristiques. Tant que l'équipe est cohérente, il est normal de se développer efficacement. Certaines règles ne sont pas quelque chose que nous devons obéir constamment. Par exemple, en termes d'indentation, nous utilisons souvent la clé de l'onglet pour être plus pratique, mais nous ne pouvons pas garantir que l'onglet représente 4 espaces dans n'importe quel environnement. Afin de maintenir la cohérence de l'indentation, si la clé de onglet est utilisée, elle doit être utilisée tout au long du processus; Et nous n'avons pas non plus à utiliser "" et "", et il est également possible d'utiliser ", tant que vous maintenez un style cohérent. Il existe de nombreux autres problèmes de style similaires, tous basés sur le choix personnel.
Il n'y a pas de règles absolues, appropriées ou non.