Archives par mot-clef : jslint

Ceux qui me suivent sur Twitter le savent déjà, je viens de lancer mon auto-entreprise. L’idée que je me suis fixé et de dispenser des formations JavaScript aux entreprises dans le cadre du DIF. Plus d’une fois en conférence, vous (peut-être, qui sait ?) êtes venus me demander si je faisais des formations sur plusieurs jours. Je répondais que non. La réponse est désormais : Oui ! Au programme, on aura donc diverses formations : JavaScript L’idée est de partir des bases du langage, l’approfondir, le comprendre. Découvrir des outils du quotidien du développeur JS, apprendre à déboguer le code et à le tester. Dans cette thématique seront abordés notamment les éléments suivants (ici en désordre) : GruntJS ; Mocha ; JSLint/JSHint ; Uglify ; JSPerf ; Chrome Dev Tools ; Firebug. jQuery Pour cette formation, je livre tout ce … Continuer la lecture

J’avais commencé il y a quelques mois une série d’articles sur JSLint et plus précisément sur les messages d’erreur qu’il peut générer. Et finalement, j’ai arrêté, encore par manque de temps. Ceci dit, je souhaite mettre une fin propre à cette série en vous proposant une source d’informations des plus correctes. JSLint Errors vous propose l’explication des erreurs JSLint et JSHint. Il y a tout un dépôt GitHub derrière et le site a l’air pas mal suivi et maintenu.

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 … Continuer la lecture

Exceptionnellement, je vous proposerai de télécharger un fichier. Celui-ci : [Lien provisoirement supprimé] C’est quoi ce truc ? Un fichier de configuration pour PhpStorm/WebStorm. Il permet de définir correctement des règles d’édition de code pour PHP et JavaScript. Comment les règles ont été définies ? Bien évidement, je n’ai pas décrété ces règles de façon totalement arbitraire. Je me suis conformé aux règles attendues par les conventions Zend Style et JSLint ainsi que JSHint. J’ai créé ce fichier pour permettre à mon équipe de remettre d’aplomb leur code et de valider les règles que nous avons défini pour Jenkins. PhpMessDetector, PhpCheckStyle et JSLint sont donc de la partie. L’essentiel de l’apport de ce fichier se situe dans deux composantes : Le style de code ; Les alertes. Le style de code En exécutant bêtement et simplement une auto-indentation du code, … Continuer la lecture

Dans la série des messages JSLint, je continue avec celui-ci : Expected ‘!==’ and instead saw ‘!=’. Équivalent aussi à ce message : Expected ‘===’ and instead saw ‘==’. Cause Prenons pour exemple ce code : if(toto != titi) { // corps } Second exemple if (toto == titi) { // corps } Le problème ici est de faire confiance à JavaScript pour la comparaison des données. C’est à dire que là vous vérifiez que la valeur est la même mais sans tenir compte du type de données. Un peu comme si vous couriez tout nu sur le périphérique parisien avec les yeux bandés et les oreilles bouchées. En gros, ça va vous péter au nez et ça va faire mal. Exemple Par exemple, avec la double égalité, ceci est vrai : ' \t\r\n' == 0 Alors que vous pouvez le … Continuer la lecture

Je démarre cette série avec le message Move ‘var’ declarations to the top of the function. Cause Prenons un exemple de code : function demo () { if(true) { var toto = true; } } Le problème ici est de ne pas avoir déclaré la variable au bon endroit. La solution En JavaScript, la portée d’une variable correspond au scope. Et celui-ci s’étend sur tout le corps de la fonction. Le code correct aurait été d’écrire ceci : function demo () { var toto; if(true) { toto = true; } } Masquer cette erreur et donc l’ignorer peut gêner dans la lisibilité du code si vous déclarez vos variables n’importe où. Tout déclarer en tête de fonction permet donc de rendre le code lisible.

J’ai pas mal de travail en ce moment mais j’ai pris le temps d’écrire sur mon temps libre quelques articles sur la validation de votre code via JSLint. En tant qu’extrémiste, faut bien que je vous taquine un peu pendant que vous êtes en vacances. Quand je me suis mis à la validation de mon code sur cet outil, j’ai passé pas mal de temps sur StackOverFlow pour comprendre certains messages. J’ai donc décidé d’écrire une série de billets pour partager avec vous ce que j’ai appris. Dans les minutes qui suivront, je publierai un premier article là dessus. Et de façon régulière, j’essaierai d’en publier d’autres. N’hésitez pas à contribuer dans les explications si vous pensez que je raconte des bêtises ou que je suis incomplet. J’espère que vous apprécierez.

Dans la série des messages JSLint, je continue avec celui-ci : Missing radix parameter. Cause Prenons pour exemple ce code : function test(a) { 'use strict'; return parseInt(a); } Le problème ici est de faire confiance à JavaScript (et oui encore) pour la transformation d’une variable de type inconnue en nombre entier. L’essentiel du temps, vous travaillerez en base 10 mais ce n’est pas systématiquement vrai. Exemple de non fonctionnement en base 10 Un grand classique : parseInt('08', 10) La solution Il est très simple de corriger ce bogue, en précisant sur quelle base numérique vous travaillez. En général, vous travaillerez en base 10. Comme ceci : function test(a) { 'use strict'; return parseInt(a, 10); } Ou pour travailler en octal function test(a) { 'use strict'; return parseInt(a, 8); } Bonus Trois précisions et un billet culturel parseFloat Ne nécessite pas … Continuer la lecture