Comparaison des outils de vérification du style de code JavaScript: jslint, jshint, jscs et eslint

Cet article comparera et analysera quatre outils de vérification de style de code JavaScript populaires: JSlint, Jshint, JSCS et Eslint pour vous aider à choisir l'outil le plus approprié pour votre projet. Ces outils aident à éviter les erreurs de codage en suivant les spécifications de codage et en identifiant les erreurs potentielles.

Points clés:

• JSLINT, JSHINT, JSCS et ESLINT JavaScript Style de vérification des outils tels que JSlint, Jshint, JSCS et Eslint aident à éviter les erreurs de codage en suivant les normes d'encodage et en identifiant les erreurs potentielles. Chaque outil présente ses propres avantages et inconvénients, et le choix de l'outil dépend des besoins spécifiques du projet.
• jslint est le plus ancien outil con?u pour appliquer de bonnes parties de JavaScript. Il n'est pas configurable et évolutif et manque de documentation. Jshint est une branche de JSlint, qui est plus facile à configurer et facile à utiliser dans les grands projets, mais nécessite une configuration pour le faire fonctionner.
• JSCS est un vérificateur de style de code qui se concentre sur le formatage de code, pas des erreurs potentielles. Il a plus de 90 règles et prend en charge des plugins personnalisés différents. Cependant, il n'est pas aussi flexible que d'autres outils et est le plus lent des quatre.
• Eslint est le dernier outil extensible avec beaucoup de règles personnalisées. Il vérifie les erreurs et autres problèmes dans le code, c'est donc le choix recommandé pour l'auteur. Il prend en charge les fonctionnalités ES6 et JSX. Cependant, sa documentation peut être déroutante et nécessite une certaine configuration.

Des années d'expérience en programmation font toujours des erreurs de bas niveau, telles que les erreurs d'orthographe dans les noms de variables, les erreurs de grammaire et l'oubli de gérer correctement les erreurs. Un bon outil de vérificateur de style de code peut repérer ces problèmes avant de perdre du temps (ou pire, du temps client). Il peut également aider les projets à se conformer aux spécifications de codage.

Il existe de nombreux outils de vérification du style de code JavaScript sur le marché, comment choisir? Jetons un coup d'?il aux fonctionnalités et avantages et inconvénients de quatre alternatives populaires: JSlint, Jshint, JSCS et Eslint.

Présentation

Ces quatre outils fonctionnent essentiellement de la même manière. Ils ont un ensemble de règles d'analyse et de signalement des problèmes dans les fichiers JavaScript. Ils peuvent être installés via NPM, utilisés à partir de la ligne de commande en passant des fichiers, utilisés comme plugins pour des outils tels que Grunt ou intégrés dans l'éditeur. Ils prennent tous en charge la configuration avec des commentaires.

mais les similitudes se terminent ici. Chaque outil a ses propres avantages et inconvénients - c'est juste que certains outils ont plus d'avantages que d'inconvénients.

jslint

jslint est le plus ancien de ces quatre outils. Douglas Crockford l'a créé en 2002 dans le but d'appliquer ce qu'il croit être une bonne partie de JavaScript. Si vous êtes d'accord avec ces bonnes pièces, JSlint peut être un bon outil - installez-le et utilisez-le.

L'inconvénient est que JSlint n'est pas configurable ou évolutif. Vous ne pouvez tout simplement pas désactiver de nombreuses fonctionnalités, et certaines d'entre elles manquent de documentation. Le site officiel n'est pas très utile, par exemple, il manque d'informations sur la fa?on de l'intégrer à votre éditeur.

PROS:

• Il est prêt à l'emploi après la configuration (si vous acceptez les règles qu'il applique).

Inconvénients:

• jslint n'a pas de fichier de configuration, ce qui peut devenir un problème si vous devez modifier les paramètres.
• Le nombre d'options de configuration est limité et de nombreuses règles ne peuvent pas être désactivées.
• Vous ne pouvez pas ajouter de règles personnalisées.
• Fonction non enregistrée.
• Il est difficile de savoir quelle règle provoque quelle erreur.

jshint

jshint est créé comme une version plus facile à configurable de JSlint (qui est une branche de JSlint). Vous pouvez configurer chaque règle et les mettre dans un fichier de configuration, ce qui rend Jshint facile à utiliser dans les grands projets. Jshint fournit également une bonne documentation pour chaque règle afin que vous sachiez exactement ce qu'ils font. L'intégrer dans l'éditeur est également simple.

Un petit inconvénient de Jshint est qu'il est livré avec une configuration par défaut lache. Cela signifie que vous devez effectuer une configuration pour le faire fonctionner. Par rapport à Eslint, il est également difficile de savoir quelles règles doivent être modifiées pour activer ou désactiver certains messages d'erreur.

PROS:

• La plupart des paramètres sont configurables.
• Prise en charge des fichiers de configuration pour les rendre plus faciles à utiliser dans les grands projets.
• Soutenez de nombreuses bibliothèques hors de la bo?te, telles que jQuery, Qunit, Nodejs, Mocha, etc.
• Support ES6 de base.

Inconvénients:

• Il est difficile de savoir quelle règle provoque l'erreur.
• a deux types d'options: obligatoire et relaxation (peut être utilisé pour rendre Jshint plus stricte ou supprimer ses avertissements). Cela peut rendre la configuration légèrement déroutante.
• Les règles personnalisées ne sont pas prises en charge.

jscs

JSCS diffère des autres outils en ce qu'il ne fait rien à moins que vous ne fournissiez un fichier de configuration ou que vous lui disiez d'utiliser un préréglage. Vous pouvez télécharger des configurations à partir de leur site Web, donc ce n'est pas un gros problème, il a beaucoup de préréglages comme JQuery Coding Style Presets et Google Presets.

Il a plus de 90 règles différentes que vous pouvez créer des règles personnalisées à l'aide de plugins. JSCS prend également en charge les programmes de rapports personnalisés, ce qui facilite l'intégration avec des outils qui nécessitent une entrée dans un format spécifique.

JSCS est un vérificateur de style de code. Cela signifie qu'il n'atteint que les problèmes liés au format de code, et non aux erreurs potentielles. Il n'est donc pas aussi flexible que d'autres outils, mais JSCS fait bien le travail si vous devez appliquer un style de codage spécifique.

PROS:

• prend en charge les programmes de rapports personnalisés, ce qui peut faciliter l'intégration avec d'autres outils.
• Les préréglages et les fichiers de configuration prêts à l'emploi peuvent vous faciliter la configuration si vous suivez l'un des styles de codage disponibles.
• Il existe un drapeau qui peut inclure des noms de règles dans le rapport, il est donc facile de savoir quelle règle provoque quelle erreur.
• Vous pouvez l'étendre à l'aide de plugins personnalisés.

Inconvénients:

• détecter uniquement les conflits de style de code. JSCS ne détecte pas les erreurs potentielles, telles que des variables inutilisées ou des variables globales inattendues, etc.
• le plus lent des quatre outils, mais ce n'est pas un problème dans une utilisation typique.

eslint

Eslint est le dernier de ces quatre outils. Il est con?u pour être facile à évoluer, avec beaucoup de règles personnalisées, et facile à installer plus de règles sous forme de plugins. Il fournit une sortie concise, mais contient des noms de règles par défaut, vous savez donc toujours quelles règles provoquent des messages d'erreur.

La documentation Eslint peut être un peu inégale. La liste des règles est facile à comprendre et à regrouper en catégories logiques, mais les instructions de configuration sont un peu déroutantes à certains endroits. Cependant, il fournit des liens vers les intégrations, les plugins et les exemples de l'éditeur en un seul endroit.

PROS:

• Flexible: Toute règle peut être commutée et de nombreuses règles ont des paramètres supplémentaires qui peuvent être ajustés.
• est très extensible et dispose de nombreux plugins.
• Sortie facile à comprendre.
• contient de nombreuses règles que l'on ne trouve pas dans d'autres outils de vérification du style de code, ce qui rend Eslint plus utile pour détecter les problèmes.
• Le meilleur support ES6 et le seul outil pour prendre en charge JSX.
• Prise en charge des programmes de rapports personnalisés.

Inconvénients:

• nécessite une configuration.
• vitesse lente, mais cela n'empêche pas l'utilisation.

recommandé

J'ai choisi Eslint parmi ces quatre outils. JSLINT est strict et peu configurable, tandis que Jshint n'a pas de mécanisme d'extension. Si vous voulez simplement vérifier le style de code, JSCS est un bon choix, mais Eslint peut le faire, et il vérifie également les erreurs et autres problèmes dans votre code.

Eslint est également un choix évident si vous souhaitez utiliser ES6 (ou ES2015 car ils semblent l'appeler ainsi maintenant). De tous les outils mentionnés, il a la prise en charge la plus étendue pour les fonctionnalités ES6.

Si vous souhaitez essayer Eslint, je l'ai simplifié pour vous en créant un guide de démarrage rapide en 5 étapes. Vous pouvez télécharger le guide de démarrage rapide Eslint en 5 étapes à partir de mon site Web.

jshint est le deuxième choix puissant. Si vous n'avez pas besoin des fonctionnalités avancées d'Eslint, Jshint peut rencontrer beaucoup de problèmes après avoir été correctement configuré. JSCS a beaucoup de règles disponibles, et c'est une excellente option si vous n'avez besoin que de vérifications de style de code (retraits, accolades, etc.).

J'hésite à recommander Jslint. D'autres outils font de même, mais n'imposent aucune règle spécifique à l'utilisateur. La seule exception est que si vous êtes d'accord avec toutes les règles qu'il applique, auquel cas cela peut être utile d'étudier.

L'outil de vérification du style de code est un excellent moyen de trouver des problèmes, mais il ne peut trouver que des erreurs que ses règles permettent. Pour attraper plus de manière fiable des erreurs, je recommande d'utiliser des tests unitaires. La révision du code peut également aider à cet objectif.

Comment vous et votre équipe assurez-vous la qualité de votre code?

FAQ sur les outils de vérification du style de code JavaScript

(La partie FAQ est omise ici car la longueur est trop longue et ne correspond pas à l'objectif pseudo-original. La partie FAQ peut être ajoutée ou modifiée selon les besoins.)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!