Logo JavaScript

JSLint, pas que de la qualité, mais aussi du débogue

Flattr this!

J'ai eu à faire, il y a quelques semaines, à l'incompréhension parmi certains collègues. Ceci face à mon insistance pour respecter un peu plus les rapports dans le rouge de JSLint sur notre serveur d'intégration continue.

Pour eux, sur le coup et en vulgarisant : "JSLint, c'est comme PHP Check Style, ça rend joli le code, mais sinon, bah on est pressés donc autre chose à faire là." (version polie).

D'une certaine façon, je les comprends, on approchés de plus en plus d'une livraison ardue après des mois de travail et des semaines épuisantes sans réel repos.

J'avais volontairement laissé JSLint en mode nazi, c'était un peu vache. Le but de ce billet de blog est de faire comprendre que JSLint n'est pas là que pour rendre le code beau. Pas mal de bugs potentiels sont détectables directement dans les rapports JSLint.

Quand celui-ci déclare par exemple qu'une variable n'est pas définie. Cela veut dire que soit vous savez pertinemment qu'elle est déclarée ailleurs. Mais attention, elle restera une globale (ou peut-être déclarée dans un scope supérieur qu'il ne connait pas). Ou alors, elle n'est pas censée être une globale (ou au dessus) et va donc potentiellement écraser une variable éponyme dans un des scopes parents. Ce qui risque de provoquer des soucis. Et vous allez vous arracher les cheveux pour trouver l'origine. Ne me dites pas que ça ne vous ait jamais arrivé.

Exemple simple. Mais terriblement parlant.

Autre exemple criard, JSLint impose de protéger vos for...in avec un contrôle qui s'assure que vous jouez bien uniquement avec les données du tableau  ou de l'objet, et pas aussi avec des trucs hérités du prototype. Idiot mais je crois au fond de moi que tout dev a déjà eu l'occasion d’être confronté au cas de "j'ai rentré 8 données dans mon tableau mais il m'en compte 9, du coup mon algo fait n'importe quoi".

Vous avez été plusieurs au cours de mes articles à propos de JSLint à me signaler que cet outil est bien mais peut se révéler trop dur, trop strict. Ça peut être le cas effectivement. Moi même parfois, je l'envoie bouler. Par exemple quand il me balance une erreur "bad for in variable". Avertissement parfois censé mais aussi très souvent totalement inintéressant et juste prise de tête à régler pour le coup quand vous avez pu garantir le bon fonctionnement malgré tout de votre méthode.

Cependant, s'appliquer une politique très dure pour coder, en se laissant de temps en temps un peu de liberté, c'est aussi s'assurer qu'on aura "toujours" un code propre et un peu plus sur que parfois surveiller un laisser aller constant.

Dernier exemple simple, on connait tous les belles horreurs que peut nous pondre parfois le changement dynamique de type. Celles qu'on rencontre en utilisant == ou !=. Oui, parfois, ces vérifications non strictes sont nécessaires. Mais l'essentiel du temps, vous savez très bien ce que vous manipulez. Pourquoi ne pas vous protéger en rajoutant une comparaison stricte ? Ça ne dépend pas vraiment d'efforts supplémentaires et est particulièrement fiable pour le coup.

Oui, JSLint est un emmerdeur, il a même été créé pour ça, pour vous emmerder. Pour vous faire hurler. Vous arracher les cheveux, mais finalement, combien de fois je l'ai remercié de me montrer la solution à un bug dans un code que je reprenais ? Je ne les compte plus.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , . Vous pouvez la mettre en favoris avec ce permalien.
  • Cyrano

    Un copain m’avait un jour qualifié de « méticuleur de mouches » : du coup, je me sens moins seul 😉
    J’ajoute quand même que fait du beau code n’est absolument pas une fin en soi : si on doit y revenir [beaucoup] plus tard, on s’arrache beaucoup moins les cheveux à parcourir les lignes, ça facilite notablement la maintenance et les évolutions.

    • http://www.mathieurobin.com/ Mathieu

      Ah je les méticule pas les mouches moi… C’est l’autre mot 😉 (je le dis pas, je voudrais pas passer PEGI18 :p)

  • Flo

    Salut

    Je vais poser une question stupide mais, kesako PHP code style ?

    :) Flo

    • http://www.mathieurobin.com/ Mathieu

      Tu fais bien de me poser cette question, c’est une erreur de ma part. Je voulais écrire « check style ». J’ai corrigé dans l’article. Si tu ne connais pas check style, je t’invite à regarder ici : http://code.google.com/p/phpcheckstyle/

Articles liés