JavaScript – Améliorer la qualité de son code (Linter, IDE, compilateur, tests et build)

Un des comportements les plus ennuyeux de JavaScript est sa gestion des erreurs. A cause de certaines librairies « wrapper » ou même de la nature dynamique du langage, il peut se produire des erreurs dîtes « silencieuses ». Ces dernières ne vont pas produire une exception mais vont simplement stopper l’exécution de la page. Et cela, le plus souvent à cause d’une faute de frappe, d’une ‘,’ qui traîne à la fin d’un bloc JSON ou d’un « ; » oublié. Rageant.

Heureusement, vous avez plusieurs solutions pour vous en sortir.

JSLint & JSHint

JSLint est un outil permettant de vérifier la qualité de votre code (avec un site encore plus moche que celui de Tomcat, belle performance). Comme ils le disent sur la homepage: « JSLint will hurt your feelings. » car les règles de bases sont assez strictes et il est peu probable que n’importe lequel de vos scripts ne passe le test en en sortant vainqueur.

http://www.jslint.com/

Un peu comme pour PMD (Java) ou FlexPMD, vous pouvez altérer les règles de base et enlever celles qui vous paraissent stupides ou trop restrictives pour ne garder que celles qui vous importent. Les outils comme JSLint pourront trouver des « , » qui traînent en fin de bloc par exemple et vous prévenir.

JSHint est un « fork » (dérivé) de JSLint qui lui va vérifier les erreurs potentielles de votre code, comme par exemple une variable déclarée au sein d’un if/else ou des boucles qui ne devraient pas être. Celui-ci a des règles plus « utiles » que JSLint.

http://www.jshint.com/

La correction d’erreurs trouvées par un Linter ou un Hinter est déjà un premier pas pour vous éviter que ces erreurs n’apparaissent. Il existent d’autres Linter que JSLint au passage.

Un bon IDE

Il est toujours mieux de voir les erreurs au moment où on les tape qu’au moment où elles se produisent. Ce n’est pas le cas pour tout le monde mais j’ai du mal à me passer d’un bon IDE pour travailler. Pour l’instant, je suis très content d’IntelliJ IDEA (ou WebStorm), qui fait du bon boulot avec le JavaScript. J’ai essayé rapidement Aptana (basé sur Eclipse) mais il m’a paru plus lent et moins fonctionnel qu’IntelliJ.

Voici quelques exemples d’aide qu’offre IntelliJ.

Auto-complétion sur tous les fichiers du projet

Voilà un truc que je n’ai pas trouvé dans Aptana (en tout cas, ça ne fonctionnait pas directement). Comme JavaScript n’a rien dans le langage pour gérer les dépendances entre les objets JavaScript, il n’est pas possible pour l’IDE de savoir exactement dans quels fichiers aller chercher les éléments nécessaires à l’auto-complétion. IntelliJ va donc scanner tous les fichiers ouverts de votre projet pour vous faire des propositions, pas seulement ce qu’il y a dans le fichier courant:

Comme vous le voyez, ce fichier ne contient aucun code mais IntelliJ va quand même me proposer des constructeurs qui se trouvent dans d’autres fichiers. Il propose en plus ce qui est dans le bon namespace en priorité, pratique.

Détection des méthodes non déclarées

Vous allez donc pouvoir éviter quelques fautes de frappe, par exemple, j’ai oublié un « i » dans cette méthode:

Vous pouvez modifier le niveau d’erreur si vous voulez que cela vous saute plus aux yeux.

Pseudo-typage des variables avec JSDoc

Découvert presque par hasard en annotant mon JavaScript pour le Google Closure Compiler, IntelliJ se sert aussi de la JSDoc pour vous proposer de meilleurs suggestions, ce qui réduit encore la possibilité d’erreur à la frappe:

Ce n’est pas « typé » au sens strict du terme mais cela donne une indication à l’IDE et à un compilateur éventuel. A noter que cela fonctionne sur les propriétés de manières transitive (les propriétés des propriétés des propriétés, …)

Blocs JSON mal formattés

Vous vous êtes forcément fait avoir à supprimer/commenter une ligne (la dernière, par hasard) d’un bloc JSON et vous taper une erreur à l’exécution.

IntelliJ va détecter ce genre d’erreur pour vous aider à les corriger rapidement:

Variable globale déclarée de manière implicite (oubli de « var)

A part vos namespace, vous devriez avoir peu de variables qui vont allez s’inscrire dans l’espace de nom global. Pour ma part, c’est le plus souvent que j’ai oublié un « this. » par habitude de l’ActionScript 3. IntelliJ vous prévient en vous disant que cette variable va être implicitement déclarée:

Les « this. » oubliés, ce sont 50% de mes erreurs en JS, je peux vous assurer qu’IntelliJ m’a fait gagner pas mal de temps.

Mauvaise utilisation de « this »

Parfois je l’oublie mais parfois je l’utilise de mauvaise manière, notamment à cause des problématiques de scope que l’on connait tous en JavaScript. IntelliJ est sympa et vous le fait savoir:

Ici, je suis dans le scope de success, mon this est donc en théorie mauvais car il correspond au scope de success et pas à celui de _initUser. Bon en fait, dans ce cas-là, IntelliJ a tort car je passe en option mon contexte d’exécution (options.context = this), ce qui existe aussi en jQuery à travers la même variable « context ». Mon contexte d’exécution sera donc ok mais ça, c’est quasiment impossible à deviner pour IntelliJ :).

Variable dupliquées

Evite certaines surprises à l’exécution:

Utiliser JSLint & JSHint directement depuis IntelliJ

Certains IDE (au moins IntelliJ) peuvent exécuter directement le Linter / Hinter. Pour IntelliJ, rendez-vous dans File > Settings puis tapez « jslint » dans la boite de recherche qui va vous mener dans le panneau Inspection:

Cochez « JSLint Validation » et tweakez les options, sinon la moitié de votre code va devenir rouge. Personnellement, les vérifications de base de IntelliJ sont suffisantes pour moi, j’ai désactivé cette option qui rendait la barre de droite illisible.

Compilateur JavaScript

Certains puristes vont sortir les fourches en entendant les mots « compilateur » et « JavaScript » mis côte-à-côte mais je veux bien sûr parler des minifier / concat qui vont vous permettre de fournir un script le plus petit possible, pour un téléchargement plus rapide. Il en existe un bon paquet, JS Minifier, YUI Compressor, UglifyJS, … choose your poison.

Comme je l’avais expliqué dans un article précédent sur la gestion des dépendances JavaScript, j’utilise le Google Closure Compiler. En mode « simple », celui-ci fait aussi bien que les autres au niveau min+concat. Mais avec quelques flags et le compilateur en mode « avancé », vous pouvez aller plus loin avec des vérifications supplémentaires, notamment au niveau des affectations et des pseudo-types. Grâce à certaines annotations à ajouter à sa JSDoc, de nouveaux warnings / erreurs pourront être générés. Par exemple la réaffectation d’une « constante » ou l’affectation d’une String à une variable déclarée comme Number.

Tests unitaires

Sur ce point, je suis loin d’être un spécialiste car je n’en ai pas encore écrit (oui, oui, je sais c’est mal).

Comme pour le reste, faites votre choix, vous avez par exemple:

Le jour où je commencerai à en écrire, je vous en dirais plus. Pour l’instant, à vous de choisir :).

Intégration au build

Maintenant que ces outils sont en place dans votre environnement de développement, il vous faudra exécuter les mêmes tests dans votre build pour vos assurer que vos versions sont toujours ok.

La plupart des Linter / Hinter, etc. peuvent être appelés en JavaScript, vous pouvez donc utiliser un Node ou un Rhino pour lancer les traitements. Si vous avez du Java en back-end et un Maven déjà tout chaud, vous pouvez utiliser Wro4j qui simplifie grandement l’intégration et la configuration de ces outils dans vos POM:

http://code.google.com/p/wro4j/

Un oubli?

Si vous pensez que j’ai oublié un outil que vous utilisez en pensez utile, n’hésitez pas à utiliser les commentaires, je suis toujours à le recherche de bonnes découvertes (comme Wro4J)!

6 réflexions au sujet de « JavaScript – Améliorer la qualité de son code (Linter, IDE, compilateur, tests et build) »

  1. Mickael

    Ce que tu montres sur IntelliJ me laisse rêveur : n’ayant pas de licence, j’utilise ce bon vieux eclipse dont le support Javascript laisse vraiment à désirer. Je n’ai pas testé Aptana, je ne sais donc pas trop ce que ça peut apporter.
    Tu n’en parles pas, c’est peut-être hors sujet (et peut-être pour un prochain post), mais je rajouterais également les outils de debug sur navigateurs (Google Chrome, Firebug etc.) dont bon nombre de fonctionnalités sont peu/pas connus (voir ici pour quelques astuces : http://www.andismith.com/blog/2011/11/25-dev-tool-secrets/).

    Répondre
  2. admin Auteur de l’article

    Salut Mickael,
    Effectivement, c’est un peu différent, cela touche plus au débug qu’à la qualité. Cela fera sans doute l’objet d’un autre billet. Sûrement basé sur les outils de Chrome qui sont juste top :)

    Pour IntelliJ, l’achat de la licence vaut le coup :P

    Fabien

    Répondre
  3. kewah

    Aux niveau des IDE, cloud9 est aussi intéressant (payant pour http://c9.io/) et il y a une version open source (buggé chez moi depuis la version 0.5.2 de node) https://github.com/ajaxorg/cloud9
    Pour l’avoir testé pendant la periode d’essaie (ouais je suis radin) j’en garde une très bonne impression, mais 15€/mois c’est trop pour moi.

    Répondre
  4. lionel

    Il y mocha (http://visionmedia.github.com/mocha/) pour les tests unitaires. Il est nécessite node.js. C’est plutôt sympa, on peut le lancer en ligne de commande et il supporte plusieurs librairies d’assertion (assert, BDD avec should.js ou expect.js) Y’a aussi plein de type de rapport différent.

    Bon j’ai pas des masses creuser mais de ce que j’en ai tester ça à l’air pas mal, les développeurs du projet sont actifs et répondent assez vite aux tickets qui pourraient être ouvert.

    Lionel

    Répondre
  5. Frédéric THOMAS

    Sur le framework basé sur ExtsJS sur lequel je bosse, j’ai utilisé jasmine, très simple et très bien comme outils pour les tests unitaire et d’acceptance (en javascript, c’est important d’en avoir du fait que c’est un langage dynamique non typé), maintenant, je vais voir l’utilisation de spike pour faire tourner un DOM et une V8 en ghost sous NodeJS et de javascript-maven pour industrialiser le tout, pratique pour les tests automatiser en équipe.

    Répondre
  6. Ping : Les acteurs du Web en ont parlé [#26] | Le blog des nouvelles technologies : Web, Technologies, Développement, Interopérabilité

Laisser un commentaire

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