Dois-je utiliser la validation JavaScript JSLint ou JSHint ?

Question

Je suis actuellement en train de valider mon JavaScript avec JSLint et de faire des progrès, il m'aide à écrire un meilleur JavaScript - en particulier en travaillant avec la bibliothèque Jquery.

Je suis maintenant tombé sur JSHint une fourchette de JSLint .
Je me demande donc, pour les applications web, qui sont en grande partie pilotées par JavaScript, quel est l'outil de validation le plus approprié ou le plus applicable pour travailler :

• JSLint ou JSHint ?

Je veux décider maintenant d'un mécanisme de validation et, à l'avenir, l'utiliser pour la validation côté client.

Et la différence entre jshint et jslint ? Veuillez expliquer dans un seul exemple javascript.

Liens :

1. jshint - http://www.jshint.com/

2. jslint - http://jslint.com/

Answer 1

TL;DR

Utilisez JSLint si vous recherchez un standard très élevé pour vous-même ou votre équipe, mais gardez à l'esprit qu'il n'est pas nécessairement le site standard, seulement a standard, dont une partie nous vient dogmatiquement de Doug Crockford.

Si vous voulez être un peu plus flexible ou si vous avez dans votre équipe quelques vieux pros qui n'adhèrent pas aux opinions de JSLint ou qui font régulièrement des allers-retours entre JavaScript et d'autres langages de la famille C, essayez JSHint.

Version complète

Deux articles avec le raisonnement derrière le fork expliquent pourquoi JSHint existe :

1. JSHint : Un raccourci communautaire de JSLint

2. Pourquoi j'ai transformé JSLint en JSHint

L'idée derrière JSLint est qu'il est piloté par la communauté plutôt que par Crockford. JSHint est généralement plus indulgent (ou du moins configurable ou agnostique) sur quelques opinions stylistiques et syntaxiques mineures pour lesquelles JSLint est très strict.

Par exemple, si vous pensez que les deux 1. y 2. ci-dessous sont bien, ou si vous voulez écrire du code avec un ou plusieurs des 1. qui ne sont pas disponibles dans 2. JSHint est fait pour vous. Si vous pensez 2. est la seule option correcte, utilisez JSLint. Je suis sûr qu'il y a d'autres différences, mais ceci en souligne quelques-unes.

1. Réussit JSHint sans problème - échoue à JSLint

   (function() {
     "use strict";
     var x=0, y=2;
     function add(val1, val2){
       return val1 + val2;
     }
     var z;
     for (var i=0; i<2; i++){
       z = add(y, x+i);
     }
   })();

2. Passe à la fois JSHint et JSLint

   (function () {
       "use strict";
       var x = 0, y = 2, i, z;
       function add(val1, val2) {
          return val1 + val2;
       }
       for (i = 0; i < 2; i += 1) {
           z = add(y, x + i);
       }
   }());

Je trouve le code de JSLint plus attrayant visuellement. Les seules caractéristiques avec lesquelles je ne suis pas d'accord sont son la haine de plus d'un var dans une fonction et de for -boucle var i = 0 déclarations et certaines des dispositions relatives à l'espacement des déclarations de fonctions.

Quelques-unes des règles d'espacement que JSLint applique ne sont pas nécessairement mauvaises, mais sont simplement en décalage avec certaines conventions d'espacement standard pour d'autres langages de la famille (C, Java, Python, etc.), souvent suivies comme des conventions en Javascript également. Comme j'écris dans plusieurs de ces langages tout au long de la journée et que je travaille avec des membres de l'équipe qui n'aiment pas les espaces blancs de style Lint dans notre code, je trouve que JSHint est un bon équilibre. Il attrape les bogues légitimes et le code très mal formé, mais ne m'aboie pas dessus comme le fait JSLint (parfois, d'une manière que je ne peux pas désactiver) pour les opinions stylistiques ou les pinaillages syntaxiques dont je ne me soucie pas.

Beaucoup de bonnes bibliothèques ne sont pas Lint'able, ce qui pour moi démontre qu'il y a une part de vérité dans l'idée qu'une partie de JSLint ne fait que pousser une version du "bon code" (qui est, en effet, du bon code). Mais encore une fois, les mêmes bibliothèques (ou d'autres bonnes) ne sont probablement pas Hint'able non plus, donc, touché.

Answer 2

[EDIT]
Cette réponse a été modifiée. Je laisse la réponse originale ci-dessous pour le contexte (sinon les commentaires n'auraient pas de sens).

Lorsque cette question a été posée à l'origine, JSLint était le principal outil de linting pour JavaScript. JSHint était un nouveau fork de JSLint, mais n'avait pas encore beaucoup divergé de l'original.

Depuis lors, JSLint est resté à peu près statique, tandis que JSHint a beaucoup changé - il a supprimé un grand nombre des règles les plus antagonistes de JSLint, a ajouté un grand nombre de nouvelles règles et est devenu généralement plus flexible. De plus, un autre outil, ESLint, est maintenant disponible, qui est encore plus flexible et possède plus d'options de règles.

Dans ma réponse initiale, j'ai dit que vous ne deviez pas vous forcer à respecter les règles de JSLint ; tant que vous comprenez pourquoi il lance un avertissement, vous pouvez juger par vous-même s'il faut modifier le code pour résoudre l'avertissement ou non.

Avec les règles ultra-strictes de JSLint de 2011, c'était un conseil raisonnable - j'ai vu très peu de jeux de codes JavaScript qui pouvaient passer un test JSLint. Cependant, avec les règles plus pragmatiques disponibles dans les outils JSHint et ESLint d'aujourd'hui, il est beaucoup plus réaliste d'essayer de faire passer votre code à travers eux sans aucun avertissement.

Il peut encore y avoir des cas où un linter se plaindra de quelque chose que vous avez fait intentionnellement -- par exemple, vous savez que vous devez toujours utiliser la fonction === mais juste pour cette fois, vous avez une bonne raison d'utiliser == . Mais même dans ce cas, avec ESLint vous avez la possibilité de spécifier eslint-disable autour de la ligne en question afin que vous puissiez toujours avoir un test Lint passant avec zéro avertissement, avec le reste de votre code obéissant à la règle. (ne faites pas ce genre de chose trop souvent !)

---

[LA RÉPONSE ORIGINALE SUIT]

Par tous les moyens, utilisez JSLint. Mais ne vous focalisez pas sur les résultats et sur la correction de tout ce qu'il signale. Il vous aidera à améliorer votre code, et il vous aidera à trouver des bogues potentiels, mais tout ce dont JSLint se plaint ne s'avère pas être un vrai problème, donc ne vous sentez pas obligé de terminer le processus avec zéro avertissement.

~~

Pratiquement tout code Javascript d'une longueur ou d'une complexité significative produira des avertissements dans JSLint, quelle que soit la qualité de son écriture. Si vous ne me croyez pas, essayez d'y faire passer des bibliothèques populaires comme JQuery.

~~

Certains avertissements de JSLint ont plus de valeur que d'autres : apprenez à connaître ceux dont il faut se méfier, et ceux qui sont moins importants. Chaque avertissement doit être pris en compte, mais ne vous sentez pas obligé de corriger votre code pour éliminer un avertissement donné ; il est tout à fait normal de regarder le code et de décider qu'il vous convient ; il arrive que les choses que JSLint n'aime pas soient en fait la bonne chose à faire.

Answer 3

Il y a un autre mature et activement développé "joueur" sur le front du linting de javascript - ESLint :

ESLint est un outil permettant d'identifier et de signaler les modèles trouvés dans les fichiers code ECMAScript/JavaScript. A bien des égards, il est similaire à JSLint et à JSHint à quelques exceptions près :

• ESLint utilise Esprima pour l'analyse du JavaScript.
• ESLint utilise un AST pour évaluer les motifs dans le code.
• ESLint est complètement pluggable, chaque règle est un chaque règle est un plugin et vous pouvez en ajouter d'autres au moment de l'exécution.

Ce qui compte vraiment ici, c'est que c'est extensible via des plugins/règles personnalisés . Il existe déjà de nombreux plugins écrits à des fins différentes. Parmi autres il y en a :

• eslint-plugin-angular (applique certaines des directives de Guide de style Angular de John Papa )
• eslint-plugin-jasmine
• eslint-plugin-backbone

Et, bien sûr, vous pouvez utiliser votre outil de construction de choix pour exécuter ESLint :

• grunt-eslint
• gulp-eslint

Answer 4

J'ai eu la même question il y a quelques semaines et j'ai évalué à la fois JSLint et JSHint.

Contrairement aux réponses à cette question, ma conclusion n'était pas :

Par tous les moyens, utilisez JSLint.

Ou :

Si vous recherchez un standard très élevé pour vous-même ou votre équipe, JSLint.

Comme vous pouvez configurer presque les mêmes règles dans JSHint que dans JSLint. Je dirais donc qu'il n'y a pas beaucoup de différence dans les règles que vous pouvez atteindre.

Les raisons de choisir l'une plutôt que l'autre sont donc plus politiques que techniques.

Nous avons finalement décidé d'opter pour JSHint pour les raisons suivantes :

• Il semble être plus configurable que JSLint.
• Il s'agit plus d'une communauté que d'un one-man-show (aussi cool soit-il). L'homme est).
• JSHint correspondait mieux à notre style de code OOTB que JSLint.

Answer 5

Avant-propos : Eh bien, ça a vite dégénéré. Mais j'ai décidé de m'en sortir. Puisse cette réponse vous être utile, à vous et aux autres lecteurs.

Indices de code

Bien que JSLint et JSHint soient de bons outils à utiliser, au fil des années, j'en suis venu à apprécier ce que mon ami @ugly_syntax appels :

un espace de conception réduit .

C'est un principe général, un peu comme un "moine zen", en limitant les choix que l'on doit faire, on peut être plus productif et créatif.

C'est pourquoi je préfère actuellement le style de code JS sans configuration :

StandardJS .

UPDATE :

Débit s'est beaucoup amélioré. Avec lui, vous pouvez ajouter des types à votre JS, ce qui vous aidera à éviter de nombreux de bugs. Mais il peut aussi rester en dehors de votre chemin, par exemple lors de l'interfaçage de JS non typé. Essayez-le !

Démarrage rapide / TL;DR

Ajouter standard comme une dépendance de votre projet

npm install --save standard

Ensuite, dans package.json ajoutez le test suivant script :

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

Pour une sortie plus élégante pendant le développement, npm install --global snazzy et l'exécuter à la place de npm test .

Note : Vérification de type contre Heuristique

Mon ami, lorsqu'il a mentionné l'espace de conception, a fait référence à Orme et je vous encourage à essayer cette langue.

Pourquoi ? JS est en fait inspiré par LISP, qui est une classe spéciale de langages, qui se trouvent être non typée . Un langage tel qu'Elm ou Purescript sont dactylographié les langages de programmation fonctionnelle.

Les types limitent votre liberté afin que le compilateur puisse vérifier et vous guider lorsque vous violez les règles du langage ou de votre propre programme, quelle que soit la taille (LOC) de votre programme.

Un collègue junior a récemment implémenté deux fois une interface réactive : une fois en Elm, une fois en React ; jetez-y un coup d'œil pour avoir une idée de ce dont je parle.

Comparez Main.elm (dactylographié) index.js (non typé, pas de tests)

(ps. notez que le code React n'est pas idiomatique et pourrait être amélioré)

Une dernière remarque,

la réalité est que JS es non typée. Qui suis-je pour suggérer programmation typée pour vous ?

Vous voyez, avec JS, nous sommes dans un domaine différent : libérés des types, nous pouvons facilement exprimer des choses qui sont difficiles ou impossibles à donner à un type approprié (ce qui peut certainement être un avantage).

Mais sans types, il n'y a pas grand-chose pour garder nos programmes sous contrôle, et nous sommes donc obligés d'introduire des tests et (dans une moindre mesure) des styles de code.

Je vous recommande d'examiner LISP (par ex. ClojureScript ) pour vous inspirer et investir dans l'essai de vos codes. Lire La voie de la sous-couche pour avoir une idée.

La paix.