Donne du style à ton JavaScript

Nous, développeurs, passons 90% de notre temps à lire du code. Nous avons tous nos petites habitudes, nos préférences visuelles, qui font que nous écrivons tous du code différemment.

Pourquoi s’intéresser à l’apparence du code ?

• Un code propre et uniforme est plus lisible, facile à comprendre et donc maintenable. Il donne l’impression d’une équipe qui travaille bien ensemble, plutôt que des développeurs travaillant indépendamment ;
• Un code conventionné, permet aux développeurs de garder leur attention sur la logique et réduit la quantité de décisions à prendre lors de son écriture.

Comment ?

Une bonne pratique classique est de mettre en place une convention de codage, qui indique la façon dont le code doit être formaté. Il est courant alors, de rédiger un document de style au début d’un projet (comme celui très complet d’airbnb). L’aspect visuel du guide est agréable pour la compréhension, mais il n’est cependant pas très pratique (ni fun) de devoir corriger les erreurs une par une durant les revues de code. Ce qui souvent revient à délaisser petit à petit la convention mise en place…

Heureusement, l’écosystème JavaScript comprend ESLint, un linter très puissant, dont les règles sont simples à configurer et qui va se charger de relever toutes les erreurs à votre place ! Ainsi en intégrant cet outil à votre workflow de développement, vous assurez à votre projet qu’il respecte une convention mise en place par l’équipe, sans efforts.

Section intitulée installationInstallation

Comme il s’agit d’un outil de développement pur, nous allons l’installer en temps que dépendance de développement :

$ npm install --save-dev eslint

Celui-ci base sa configuration sur un fichier .eslintrc (ou bien sur le champ eslintConfig de votre fichier package.json). Pour le moment, ajoutez simplement le fichier .eslintrc suivant :

{
  "extends": "eslint:recommended", // Ajoute quelques règles par défaut
  "rules": {
    "quotes": [2, "single"], // On modifie cette règle car on préfère les single quotes
    "no-alert": 0 // On désactive cette règle car notre projet utilise `alert()`
  }
}

Ensuite, éditez votre package.json afin d’ajouter le script suivant :

{
  #...
  "scripts": {
    "lint": "./node_modules/eslint/bin/eslint.js --cache --fix ./app"
  }
}

Ainsi, un simple npm run lint exécutera le linter et on évite à toute l’équipe d’avoir à installer le module en global.

L’option --cache nous permet de créer un fichier de cache (.eslintcache) qu’ESLint va utiliser pour enregistrer les fichiers sans erreurs et éviter de se relancer s’ils n’ont pas été modifiés.

L’option --fix permet de corriger automatiquement certaines erreurs.

Enfin, ./app correspond au chemin vers les fichiers sources de votre application, par défaut uniquement les fichiers .js sont parcourus.

Ensuite, pour relancer le linter à chaque modification de fichiers, nous l’ajoutons à notre outil de build préféré. Brunch dispose de son propre plugin et Webpack de son propre loader. D’autres intégrations sont possibles pour les différents outils ou encore la plupart des IDEs. Peu importe ce que vous choisissez, l’important est d’avoir un retour très rapide de l’exécution du linter. Vérifier le résultat du linter avant même votre application est un bon moyen d’éviter de nombreux bugs.

Pensez également à ajouter le script dans votre intégration continue, de préférence dans un hook dédié. Enfin, ajouter le script en tant que pre-commit, permet d’assurer que chaque commit du projet respecte la convention.

Passons désormais au choix des règles à appliquer. Sur un nouveau projet, il me parait important d’adopter une convention stricte dès le début, il sera toujours possible d’ajuster les règles plus tard, si l’équipe les trouve trop strictes. En revanche, sur un projet avec une base de code déjà conséquente, nous préférerons ajouter des règles au fur et à mesure pour éviter de crouler sous les warnings.

Section intitulée pour-vous-donner-envie-voici-une-selection-de-regles-utilesPour vous donner envie, voici une sélection de règles utiles

Règles purement syntaxiques :

• camelcase : Configurée avec {"properties": "always"}, elle permet de vérifier que vos variables sont toutes nommées avec la notation camelCase.
• quotes : Permet de choisir définitivement entre les single et double quotes.

Beaucoup d’autres (comma-spacing, comma-style, key-spacing…), pour détecter les « ; » ou «, » oubliés, éviter les espaces ou saut de lignes inutiles.

Règles pour garder un code propre :

• no-unused-vars : Permet d’éviter les variables déclarées mais non utilisées qui prennent de la place pour rien dans le code.
• no-shadow : Évite de déclarer une variable avec le même nom qu’une autre de portée supérieure.
• strict : En configurant avec never, empêche l’utilisation de use strict (inutile si vous utilisez babel, puisqu’il s’en charge).

Section intitulée encore-plus-loinEncore plus loin…

Eslint est encore plus intéressant en ajoutant le support d’ECMAScript 6/7 via babel et de règles spécifiques à React via le plugin dédié. Ajoutons, donc ces nouveaux modules :

npm install --save-dev babel-eslint eslint-plugin-react

Règles ECMAScript2015 :

• no-var : Force l’utilisation de let ou de const, à coupler avec prefer-const, qui suggère d’utiliser const quand une variable n’est pas modifiée.
• prefer-arrow-callback : Vérifie l’utilisation de fonctions fléchées pour vos callbacks.

Règles React :

• react/prop-types : Vérifie que toutes vos props ont bien une validation de type.
• react/no-did-mount-set-state : Vérifie que setState n’est pas utilisé dans la méthode componentDidMount.
• react/prefer-es6-class : Permet de privilégier la syntaxe ES6 de React plutôt que la méthode React.createClass.
• react/no-unknown-property : Va détecter que vous avez écrit class à la place de className par exemple.

Beaucoup de règles sont dédiées à la syntaxe jsx comme: react/jsx-key, react/jsx-max-props-per-line.

Règles personnalisées :

Il est possible de définir ses propres règles, par exemple, si elles sont liées à votre application (un warning d’appel à une API dépréciée, …)

Section intitulée partager-sa-configurationPartager sa configuration

ESLint propose d’étendre facilement les configurations partagées, à installer en comme n’importe quel module. Cela a été fait par airbnb et ça permet d’utiliser un socle de règles important sans passer trop de temps à les configurer !

Chez JoliCode, nous avons décidé de partager nos conventions dans le dépôt codingstyle, vous y trouverez ainsi notre configuration ESLint (eslint-config-jolicode), mais aussi PHP-CS-Fixer et autre editorConfig.

Avec ces quelques fichiers, nous pouvons mettre en place très rapidement une convention commune, et plutôt que d’avoir, sur chaque projet, des styles différents, nous essayons maintenant d’être cohérent aussi entre les projets.

Nous vous invitons à partager votre propre configuration, cependant pour utiliser la notre, suivez la procédure d’installation et modifiez ainsi votre fichier .eslintrc :

{
  "extends": "jolicode"
}

Adoptez une convention, c’est pour votre bien !