Comment assurer le respect des conventions de votre projet Comment assurer le respect des conventions de votre projet

Comment assurer le respect des conventions de votre projet

par ,
le 19 novembre 2014

0
0

Lectorat : développeurs front-end (tout niveau)
TL;DR : à défaut ou en plus de bien coder : il faut s’obliger (et ses collègues) à coder droit.


Comment se faire haïr par un développeur js ? Rien de plus facile, il suffit juste de modifier partiellement ses fichiers indentés avec des tabulations par des séries de deux espaces. Ou le contraire. Ou de quatre espaces. Ou d’un autre nombre… Voire d’un nombre variant au hasard d’une ligne à l’autre. Et encore, quand il y a de l’indentation…

“ …avec du style / le style avant tout ”

Même si l’indentation n’a pas d’effet sur l’interprétation du code en javascript (alors qu’elle est très importante en python, sass, jade…), elle est plus qu’un simple effet de style. Certes, c’est comme les commentaires, ça gonfle la taille du fichier — mais de toute façon c’est un fichier minifié qui est mis en production, alors autant prendre ses aises en développement, n’est-ce pas ? Un code clair et facile à lire a moins de chance de contenir de bugs, car il facilite la compréhension de son fonctionnement.

Un exemple. C’est quand même plus aisé de repérer très rapidement la grosse boulette dans

[cc lang= »js » noborder= »true » theme= »blackboard » escaped= »true »]function foo() {
var a = 2
// some code
if (a > 0) {
// some other code
let b = 4
// more code
// and yet more code
}
/* final lines of code */
return (a + b)
}[/cc]

que dans

[cc lang= »js » noborder= »true » theme= »blackboard » escaped= »true »]function foo() {
var a =2
// some code
if ( a >0)
{ // some other code
let b= 4
// more code
// and yet more code
}/* final lines of code*/ return (a +b)}[/cc]

…non ? (*)

Alors que faire ? Si vous travaillez seul(e) dans votre coin et continuerez ainsi pendant les dix prochaines années, faites comme bon vous semble. Si quelqu’un est susceptible de reprendre votre travail par la suite, il faudrait quand même faire un peu de ménage. Pour elle ou lui. Et aussi (surtout ?) pour vous, quand vous reviendrez sur votre ouvrage quelques semaines plus tard et aurez envie d’étrangler votre moi du passé.

L’idéal serait d’avoir des guidelines sur la manière d’indenter, une charte établissant une fois pour toute combien d’espaces par indentation (ou si la tabulation est utilisée). Et de la communiquer avec les collaborateurs du projet.
Oh, et puis, si ces guidelines pouvaient aussi concerner la déclaration unique ou multiple par [cc inline= »true »]var[/cc]… les espace ou non entourant les [cc inline= »true »]:[/cc] dans la déclaration d’un objet… l’accolade ouvrante sur la même ligne que le [cc inline= »true »]if[/cc] ou à la ligne suivante… sans oublier ça ça et ça…
A tant faire qu’on est dans la liste au Père Noël, il faudrait un outil qui permette de vérifier qu’on ne s’est pas pris les pieds dans le tapis en cours de route.

Bingo. JSCS (JavaScript Code Style) est pour vous et vos collègues. Une soixantaine de règles de validation afin de pouvoir décider dès le départ quelle doit être la « bonne » manière d’écrire du code pour ce projet en question. Ou pour se fondre dans le style d’un projet existant.

Etudiez chacune de ces règles et créez un fichier [cc inline= »true »].jscsrc[/cc] pour sauvegardez l’ensemble des préférences. L’idéal est certes d’avoir un fichier à la racine de votre répertoire utilisateur, histoire d’avoir des règles « par défaut » et vous obliger de respecter vos propres règles, mais surtout d’avoir un [cc inline= »true »].jscsrc[/cc] à la racine de chaque projet afin d’établir les règles communes du projet en question.

Pour valider un fichier selon les règles, au choix :
– le package npm est installé globalement ; vous vérifiez votre js avec une ligne de commande dans le terminal. C’est fastidieux à la longue, mais vous êtes masochiste, vi est votre ami.
– le package npm est installé localement, dans le projet en cours, et vous passez par gulp ou grunt pour automatiser la tâche « je sauvegarde et je vérifie ». C’est déjà mieux qu’avant et vous aimez avoir des frissons quand vous regardez enfin ce qui se passe dans votre terminal. Ou encore vous travaillez avec Notepad / TextEdit.
– votre éditeur favori (Sublime Text, Atom, Brackets…) a un plugin JSCS, ce qui lui permettra de vous avertir dès la saisie du code qu’il y a un problème. Magie du direct : plus il y a de loupiottes allumées, plus vous vous faites enguirlander, plus vite vous résolvez.

“ …Here life is beautiful. Even the JS is beautiful! ”

Vous intervenez sur un projet existant, du code doit être ajouté, et le médecin légiste en vous hésite entre conclure à une concaténation hasardeuse entre différents fichiers et une succession de codeurs plus ou moins pressés et habiles. Autre possibilité, vous héritez d’un fichier minifié. Bref, l’ajout de vos propres bouts de code au bon endroit ne va pas être forcément facilité. Commencer à tout décomposer à la mano, c’est aussi bienvenu que chronophage, sans compter le risque de faire des erreurs.

Reprenons notre liste de souhaits : et s’il existait un outil pour déminifier ou ré-indenter correctement un fichier ? Selon des règles bien choisies, bien-sûr. Air connu.

JS Beautifier est là pour vous aider, avec vos préférences enregistrées dans un [cc inline= »true »].jsbeautifyrc[/cc] à placer dans votre répertoire utilisateur, ou le cas échéant, à la racine du projet. Comme précédemment, le package npm installé globalement permet d’utiliser la ligne de commande, et des plugins existent pour votre éditeur favori. Petit bonus: il va vous permettre d’effectuer le même travail sur les fichiers html et css. Pratique dans ce dernier cas si stylus, où l’indentation est porteuse de sens, est par ailleurs utilisé dans le projet en cours.

Notez que JS Beautifier est quand meme un moyen assez drastique de réécrire un fichier. Il n’est pas forcément judicieux d’apporter des modifications à chaque ligne uniquement pour améliorer la lisibilité d’un fichier existant depuis longtemps, et pourrir inutilement ainsi votre commit git. Appuyez sept fois sur escape avant de lancer la commande ou la macro.

“ …What the hell am I doing here? ”

JSCS et JS Beautifier permettent d’écrire du code js bien présenté. Mais ils ne vont certainement pas vous éviter de faire des erreurs ici et là.

A mi-chemin entre le respect d’un style de coder et les alertes d’erreurs potentielles et d’erreurs effectives, JSHint et son fichier de préférence [cc inline= »true »].jshintrc[/cc] est un outil qui s’avère vite indispensable au quotidien.
Là encore, au choix, installation du package au niveau global, ou au niveau local dans le cadre de tâches [cc inline= »true »]gulp[/cc] ou [cc inline= »true »]grunt[/cc], ou via un plugin pour votre éditeur.

Certains réglages de style font clairement doublon avec JSCS (…l’indentation, par exemple), d’autres sont en supplément, comme le fait de forcer de terminer toutes ses lignes par un [cc inline= »true »];[/cc] (et faire plaisir à Douglas Crockford).

L’intérêt de JSHint est le lancement d’alertes, bien utile pour éviter les plantages par faute d’inattention.

Oups, vous avez déclaré des variables, mais vous ne faites rien avec. Au contraire, vous vous servez d’une variable qui n’a pas été déclarée (exemple typique où, dans un module, [cc inline= »true »]foo()[/cc] est utilisé par erreur au lieu de [cc inline= »true »]this.foo()[/cc]…) Trop de boucles [cc inline= »true »]if[/cc] sont nichées à l’intérieur de boucles [cc inline= »true »]if[/cc]. Vous étendez des prototypes d’objets natifs comme [cc inline= »true »]Array[/cc]ou [cc inline= »true »]Date[/cc]. Vous utilisez des blocs vides. Vous avez entré une espace insécable au lieu d’une espace. Vous avez omis d’être en [cc inline= »true »]strict mode[/cc]. Etc.
Toute une liste de considérations à étudier point par point, ne serait-ce que pour être consistent avec ses choix et s’y tenir.

Comme précédemment, la présence de [cc inline= »true »].jshintrc[/cc] à la racine d’un projet oblige tout développeur à respecter la manière de coder sur ce projet, même s’il ou elle n’est pas forcément d’accord avec les options retenues.

Vous avez pris l’habitude d’avoir un tel outil sous le clavier pour vérifier votre js ? Parfait : faites donc de même pour votre JSX avec JSXHint, votre CSS avec CSSLint, votre SCSS avec SCSS-Lint, etc…

 

En conclusion : soyez rigoureux, utilisez JSHint et JSCS ! Présents dans tous les bons repos.


(*) l’erreur est que [cc inline= »true »]b[/cc] n’est pas défini au moment du [cc inline= »true »]return[/cc]. En effet, [cc inline= »true »]let[/cc] (un ajout de ES6) permet de déclarer une variable et de limiter son existence à l’intérieur d’un scope bien restreint, pas juste la fonction en cours ou le global.
Dans l’exemple ci-dessus, [cc inline= »true »]b[/cc] n’existe qu’à l’intérieur de la boucle [cc inline= »true »]if[/cc] ; retourner la somme [cc inline= »true »]a+b[/cc] est donc impossible. En indentant correctement son code, on voit tout de suite les limites du scope de [cc inline= »true »]let b=4[/cc]… Enfin, un peu plus facilement. Cf l’article de David Walsh pour en apprendre plus sur [cc inline= »true »]let[/cc].

mots-clés :

,

articles à lire ensuite...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

0
0

Comment assurer le respect des conventions de votre projet