Question Dois-je utiliser la validation JSLint ou JSHint JavaScript?


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

J'ai maintenant rencontré JSHint, une fourchette de JSLint.
Donc, je me demande pour les applications Web, qui sont très axées sur JavaScript, qui est le meilleur outil de validation applicable:

  • JSLint ou JSHint?

Je veux décider maintenant d'un mécanisme de validation et aller de l'avant, utilisez ceci pour la validation côté client.

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

Liens:

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

  2. jslint- http://jslint.com


436
2017-07-23 21:04


origine


Réponses:


[MODIFIER]
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 filtrage de JavaScript. JSHint était une nouvelle branche de JSLint, mais n'avait pas encore beaucoup divergé de l'original.

Depuis lors, JSLint est restée à peu près statique, alors que JSHint a beaucoup changé - elle a jeté beaucoup de règles plus antagonistes de JSLint, a ajouté un tas de nouvelles règles et est généralement devenue plus flexible. En outre, un autre outil ESLint est maintenant disponible, qui est encore plus flexible et dispose de plus 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 compreniez pourquoi il émettait un avertissement, vous pourriez décider vous-même si vous souhaitez modifier le code pour résoudre l’avertissement ou non.

Avec le jeu de règles ultra-strict de JSLint à partir de 2011, c'était un conseil raisonnable - j'ai vu très peu de jeux de codes JavaScript capables de réussir 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 aucun avertissement.

Il peut encore arriver que des hommes se plaignent de quelque chose que vous avez fait intentionnellement - par exemple, vous savez que vous devez toujours utiliser === mais juste cette fois, vous avez une bonne raison d'utiliser ==. Mais même avec ESLint, vous avez la possibilité de spécifier eslint-disable autour de la ligne en question de sorte que vous pouvez toujours avoir un test de charpie passante avec des avertissements zéro, 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]

Bien sûr, utilisez JSLint. Mais ne vous attardez pas sur les résultats et sur la réparation de tout ce qu’il avertit. Cela vous aidera à améliorer votre code, et cela vous aidera à trouver des bogues potentiels, mais tout ce dont JSLint se plaint ne s'avère pas être un véritable problème, alors ne vous sentez pas obligé de terminer le processus avec des avertissements zéro.

Pratiquement tout code Javascript de longueur ou de complexité significative produira des avertissements dans JSLint, aussi bien écrit soit-il. Si vous ne me croyez pas, essayez d’exécuter certaines bibliothèques populaires comme JQuery.

Certains avertissements JSLint ont plus de valeur que d'autres: apprenez quels sont ceux à surveiller et lesquels sont moins importants. Chaque avertissement devrait être considéré, mais ne vous sentez pas obligé de fixer votre code pour effacer un avertissement donné; il est tout à fait correct de regarder le code et de décider que vous êtes satisfait; il y a des moments où les choses que JSlint n'aime pas sont en fait la bonne chose à faire.


145
2017-07-23 22:00



tl; dr à emporter:

Si vous recherchez un niveau très élevé pour vous-même ou votre équipe, JSLint. Mais ce n'est pas forcément 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 de vieux pros de votre équipe qui n'apprécient pas les opinions de JSLint, ou qui font régulièrement la navette entre JS et d'autres langues de la famille C, essayez JSHint.

version longue:

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

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint  http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/

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

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

A) Transmet 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 difficiles avec lesquelles je suis en désaccord sont ses haine de plus d'une déclaration var dans une fonction et de for-loop var i = 0 déclarations, et certaines des applications des espaces pour les déclarations de fonctions.

Quelques-unes des choses que JSLint impose, je trouve qu'elles ne sont pas nécessairement mauvaises, mais désynchronisées avec d'autres conventions d'espaces standards pour d'autres langages de la famille (C, Java, Python, etc ...), qui sont souvent suivi comme conventions 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 blancs dans notre code, JSHint est un bon équilibre. Il attrape des choses qui sont un bug légitime ou une forme vraiment mauvaise, mais ne m'aboie pas comme JSLint le fait (parfois, d'une manière que je ne peux pas désactiver) pour les opinions stylistiques ou nitpicks syntaxiques dont je ne me soucie pas.

Beaucoup de bonnes bibliothèques ne sont pas connectables, ce qui démontre à mon sens qu'il y a une part de vérité dans l'idée que JSLint ne fait que pousser une version de "bon code" (qui est, en fait, 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, toucher.


368
2018-05-26 04:36



Il y en a un autre mature et activement développé "player" sur le front de javascript ESLint:

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

  • ESLint utilise Esprima pour l'analyse syntaxique JavaScript.
  • ESLint utilise un AST pour évaluer les modèles dans le code.
  • ESLint est complètement enfichable, chaque   La règle unique est un plugin et vous pouvez en ajouter d'autres à 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à plusieurs plugins écrits à des fins différentes. Parmi autres, il y a:

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


54
2017-12-23 06:20



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

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

Bien sûr, utilisez JSLint.

Ou:

Si vous recherchez un niveau 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. Donc, je dirais qu'il n'y a pas beaucoup de différence dans les règles que vous pourriez atteindre.

Donc, les raisons de choisir l'une sur l'autre sont plus politiques que techniques.

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

  • Semble être plus configurable que JSLint.
  • Il semble définitivement plus axé sur la communauté plutôt que sur un homme-spectacle (peu importe comment cool L'homme est).
  • JSHint correspondait mieux à notre style de code OOTB que JSLint.

16
2017-12-22 14:45



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

Le compilateur de fermeture est un outil pour effectuer le téléchargement de JavaScript et courir plus vite. C'est un vrai compilateur pour JavaScript. Au lieu de compiler d'un langage source vers un code machine, il compile du JavaScript vers un meilleur JavaScript. Il analyse votre JavaScript, l'analyse, supprime le code mort et réécrit et minimise ce qui reste. Il vérifie également la syntaxe, les références aux variables et les types, et signale les pièges JavaScript courants.


12
2017-07-23 21:07



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

I got a bit carried away here

Indication de code

Alors que JSLint et JSHint sont de bons outils à utiliser, au fil des années, je suis venu à apprécier ce que mon ami @ugly_syntax appels:

espace de conception plus petit.

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 créatif.

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

StandardJS.

METTRE À JOUR:

Couler a beaucoup amélioré. Avec ça, vous peut ajouter des types à votre JS avec vous aidera à prévenir beaucoup de bugs. Mais il peut également rester hors de votre chemin, par exemple lors de l'interfaçage de JS non typé. Essaie!

Démarrage rapide / TL; DR

Ajouter standard comme une dépendance à votre projet

npm install --save standard

Puis dans package.json, ajoutez le script de test suivant:

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

Pour une sortie plus silencieuse en cours de développement, npm install --global snazzy et exécutez-le au lieu de npm test.

Remarque: vérification de type versus heuristique

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

Pourquoi? JS est en fait inspiré par LISP, qui est une classe spéciale de langues, qui se trouve être non typé. Langue comme Elm ou Purescript sont tapé langages de programmation fonctionnels.

Type restreint votre liberté pour que le compilateur puisse vérifier et vous guider lorsque vous violez la langue ou les règles de votre propre programme; indépendamment de la taille (LOC) de votre programme.

Récemment, un collègue junior a implémenté une interface réactive deux fois: une fois dans Elm, une fois dans React; jeter un oeil pour avoir une idée de ce dont je parle.

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

(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 suggérer programmation typée à toi?

Voir, 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 choses à faire pour 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 de regarder LISP (par ex. ClojureScript) d'inspiration et d'investir dans le test de vos codes. Lis Le chemin du sous-stade pour avoir une idée.

Paix.


10
2018-01-23 18:23



Eh bien, au lieu de faire des réglages manuels de la fibre, nous pouvons inclure tous les paramètres de la fibre en haut de notre fichier JS lui-même.

Déclarez toutes les var globales dans ce fichier comme:

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

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

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

J'espère que ceci vous aidera :)


8
2017-09-17 13:02



Il y a aussi une autre alternative activement développée - JSCS - Style de code JavaScript:

JSCS est un linter de style de code pour l'application par programme de votre style   guider. Vous pouvez configurer JSCS pour votre projet en détail en utilisant   150 règles de validation, y compris des préréglages de guides de style populaires comme   jQuery, Airbnb, Google, et plus encore.

Il vient avec plusieurs presets que vous pouvez choisir en spécifiant simplement la preset dans le .jscsrc fichier de configuration et le personnaliser - remplacer, activer ou désactiver les règles:

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

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

Regarde aussi:


1
2017-08-25 15:58