web-dev-qa-db-fra.com

Devrais-je utiliser la validation JavaScript JSLint ou JSHint?

Je suis en train de valider mon code JavaScript par rapport à JSLint et de progresser, cela m'aide à écrire un meilleur code JavaScript, en particulier en travaillant avec la bibliothèque Jquery.

Je viens maintenant de rencontrer JSHint , un fork de JSLint .
Je me pose donc des questions sur les applications Web, qui reposent en grande partie sur JavaScript. C’est le meilleur ou le plus applicable des outils de validation pour contrer:

  • JSLint ou JSHint?

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

Et différence entre jshint et jslint? S'il vous plaît expliquer en exemple javascript unique.

Liens:

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

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

javascriptjslintjshint
448
amateur

[EDIT]
Cette réponse a été modifiée. Je laisse la réponse originale ci-dessous pour contexte (sinon les commentaires n'auraient aucun 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, alors que JSHint a beaucoup changé: il a jeté beaucoup de règles plus antagonistes de JSLint, ajouté de nombreuses nouvelles règles et est devenu généralement plus flexible. En outre, un autre outil ESLint est maintenant disponible, qui est encore plus flexible et comporte davantage d'options de règles.

Dans ma réponse initiale, j'ai dit que vous ne devriez pas vous forcer à respecter les règles de JSLint; tant que vous comprenez pourquoi un avertissement a été lancé, vous pouvez décider vous-même s'il faut changer le code pour résoudre l'avertissement ou non.

Avec le jeu de règles ultra-strict de JSLint de 2011, c'était un conseil raisonnable: j'ai vu très peu de jeux de codes JavaScript pouvant passer un test JSLint. Cependant, avec les règles plus pragmatiques disponibles dans les outils JSHint et ESLint actuels, il est beaucoup plus réaliste d'essayer de faire passer votre code sans les avertir.

Il peut arriver que, parfois, un linter se plaint de quelque chose que vous avez fait intentionnellement - par exemple, vous savez que vous devez toujours utiliser === mais ce n'est que cette fois que 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 de sorte que vous puissiez toujours avoir un test de la réussite avec zéro avertissement, le reste de votre code obéissant à la règle. (mais ne faites pas ce genre de chose trop souvent!)

[RÉPONSES ORIGINALES SUIVANT]

Utilisez bien sûr JSLint. Mais ne vous attardez pas sur les résultats et sur la résolution de tout ce qui est mis en garde. Cela vous aidera à améliorer votre code et à trouver des bogues potentiels, mais tout ce dont JSLint se plaint ne s'avère pas être un réel problème. Ne vous sentez donc pas obligé de terminer le processus avec zéro avertissement.

Quasiment tout code Javascript de longueur ou de complexité significative produira des avertissements dans JSLint, quelle que soit sa qualité rédactionnelle. Si vous ne me croyez pas, essayez de faire fonctionner certaines bibliothèques populaires telles que JQuery.

Certains avertissements JSLint ont plus de valeur que d’autres: déterminez lesquels doivent être surveillés et lesquels sont moins importants. Chaque avertissement doit être pris en compte, mais ne vous sentez pas obligé de corriger votre code pour effacer tout avertissement donné; Il est tout à fait correct de regarder le code et de décider que vous en êtes satisfait. il y a des moments où les choses que JSlint n'aime pas sont en fait la bonne chose à faire.

152
Spudley

tl; dr à emporter :

Si vous recherchez un niveau très élevé pour vous ou votre équipe, JSLint. Mais ce n'est pas nécessairement LA norme, juste une norme, dont certaines nous viennent dogmatiquement d'un dieu javascript nommé Doug Crockford. Si vous voulez être un peu plus flexible, ou si vous avez quelques vieux professionnels de votre équipe qui ne souscrivent pas aux opinions de JSLint, ou qui échangez régulièrement entre JS et d'autres langues de la famille C, essayez JSHint.

version longue :

Le raisonnement derrière la fourchette explique assez bien pourquoi JSHint existe:

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslinthttp://anton.kovalyov.net/2011/02/ 20/pourquoi-je-forké-jslint-à-jshint /

Donc, je suppose que l'idée est que c'est "axé sur la communauté" plutôt que sur Crockford. En pratique, JSHint est généralement un peu plus indulgent (ou au moins configurable ou agnostique) sur quelques "opinions" stylistiques et syntaxiques mineures sur lesquelles JSLint est un stickler.

Par exemple, si vous pensez que A et B ci-dessous conviennent, ou si vous souhaitez écrire du code avec un ou plusieurs aspects de A non disponibles en B, JSHint est fait pour vous. Si vous pensez que B est la seule option correcte ... JSLint. Je suis sûr qu'il y a d'autres différences, mais cela en souligne quelques unes.

A) Passe JSHint hors de la boîte - é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);
  }
})();

B) 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);
    }
}());

Personnellement, je trouve le code JSLint très agréable à regarder, et les seules caractéristiques dures avec lesquelles je ne suis pas d’accord sont ses haine de plusieurs déclarations var dans une fonction et de déclarations for-loop var i = 0 , et certaines des applications d'espaces pour les déclarations de fonction.

JSLint applique quelques-uns des éléments d'espaces, que je trouve non pas nécessairement mauvais, mais non synchronisé avec certaines conventions d'espaces standard assez standards pour les autres langages de la famille (C, Java, Python, etc.), qui sont souvent suivi comme convention en Javascript aussi. Puisque j'écris dans plusieurs de ces langues tout au long de la journée et que je travaille avec des membres de l'équipe qui n'aiment pas les espaces de style Lint dans notre code, je trouve que JSHint est un bon équilibre. Il détecte des bogues légitimes ou de très mauvaise forme, mais ne m'aboie pas comme le fait JSLint (parfois, d'une manière que je ne peux pas désactiver) pour les opinions stylistiques ou les punaises 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 est vrai que JSLint est simplement une version de "bon code" (qui est en fait un bon code). Mais là encore, les mêmes bibliothèques (ou d'autres bonnes) ne sont probablement pas non plus Hint'able, donc, touché.

369
Ben Roberts

Il existe un autre "joueur" mature et activement développé sur le front en javascript - ESLint :

ESLint est un outil d'identification et de génération de rapports sur les modèles trouvés dans le code ECMAScript/JavaScript. À bien des égards, il ressemble à JSLint et JSHint à quelques exceptions près:

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

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

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

59
alecxe

J'avais la même question il y a quelques semaines et évaluais à la fois JSLint et JSHint.

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

Utilisez bien sûr JSLint.

Ou:

Si vous recherchez un niveau très élevé pour vous 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 appliquer.

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

Nous avons finalement décidé d’utiliser JSHint pour les raisons suivantes:

  • Semble être plus configurable que JSLint.
  • Semble nettement plus axé sur la communauté que sur une seule personne (peu importe sa fraîcheur The Man est).
  • JSHint correspondait à notre style de code OOTB meilleur que JSLint.
17
lexicore

Je ferais une troisième suggestion, compilateur Google Closure (et aussi le Closure Linter ). Vous pouvez l'essayer en ligne ici .

Le compilateur Closure est un outil permettant de télécharger et d’exécuter JavaScript plus rapidement. C'est un vrai compilateur pour JavaScript. Au lieu de compiler du langage source en code machine, il compile à partir de JavaScript pour améliorer JavaScript. Il analyse votre JavaScript, l’analyse, supprime le code mort, réécrit et minimise ce qui reste. Il vérifie également la syntaxe, les références de variable et les types, et met en garde contre les pièges JavaScript courants.

13
Jeff Foster

Avant-propos: Eh bien, cela a dégénéré rapidement. Mais a décidé de le tirer à travers. Puisse cette réponse vous être utile, à vous et aux autres lecteurs.

I got a bit carried away here

Indice de code

Bien que JSLint et JSHint soient de bons outils à utiliser, au fil des années, j’ai appris à apprécier ce que mon ami @ ugly_syntax appelle:

espace de conception réduit .

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

Par conséquent, mon style de code JS préféré de zero-config:

StandardJS .

UPDATE:

Flow s'est beaucoup amélioré. Avec lui, vous pouvez ajouter des types à votre JS pour vous aider à éviter beaucoup de bugs. Mais il peut également rester en dehors de votre chemin, par exemple lors de l’interfaçage de JS non typés. Essaie!

Quickstart/TL; DR

Ajoutez standard comme dépendance de votre projet

_npm install --save standard
_

Ensuite, dans _package.json_, ajoutez le script de test suivant:

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

Pour une sortie plus brillante lors du développement, npm install --global snazzy et exécutez-le à la place de _npm test_.

Remarque: Vérification de type ou heuristique

Mon ami en mentionnant l'espace de conception mentionné Elm et je vous encourage à essayer cette langue.

Pourquoi? JS est en fait inspiré de LISP, qui est une classe spéciale de langages, qui se trouve être non typé . Les langages tels que Elm ou Purescript sont des langages de programmation fonctionnels typés .

Tapez restreindre votre liberté pour que le compilateur puisse vérifier et vous guider lorsque vous finissez par enfreindre le langage ou les règles de votre propre programme; quelle que soit la taille (LOC) de votre programme.

Nous avons récemment demandé à un collègue junior de mettre en œuvre une interface réactive à deux reprises: une fois à Elm, une fois dans React; jetez un coup d'œil pour avoir une idée de ce dont je parle.

Comparez Main.Elm (saisi) ⇔ index.js (non typé, pas de test)

(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 est non typé. Qui suis-je pour vous suggérer une programmation typée ?

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 y a peu de moyens de contrôler nos programmes, nous sommes donc obligés d'introduire des tests et (dans une moindre mesure) des styles de code.

Je vous recommande d’inspirer LISP (par exemple ClojureScript ) et d’investir dans le test de vos codes. Lire Le chemin de la sous-pile pour avoir une idée.

Paix.

12
wires

Au lieu de définir manuellement les paramètres de charpie, nous pouvons inclure tous les paramètres de charpie en haut de notre fichier JS, par exemple.

Déclarez toutes les variables globales dans ce fichier comme ceci:

/*global require,dojo,dojoConfig,alert */

Déclarez tous les paramètres de charpie comme:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

J'espère que cela vous aidera :)

8
Vikash Pandey

Il existe également une autre alternative activement développée - JSCS - Style de code JavaScript :

JSCS est un linter de style de code pour appliquer votre guide de style par programmation. Vous pouvez configurer JSCS pour votre projet en détail à l'aide de plus de 150 règles de validation, notamment des préréglages de guides de style populaires tels que jQuery, Airbnb, Google, etc.

Il est livré avec plusieurs préréglages parmi lesquels vous pouvez choisir simplement en spécifiant le preset dans le fichier de configuration .jscsrc et en le personnalisant - remplacez, activez ou désactivez toutes les règles:

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

Il existe également des plugins et des extensions conçus pour les éditeurs populaires.

Regarde aussi:

1
alecxe