¿Debo utilizar la validación de JavaScript JSLint o JSHint? [cerrado]
Actualmente estoy validando mi JavaScript con JSLint y estoy progresando; me está ayudando a escribir mejor JavaScript, en particular al trabajar con la biblioteca Jquery.
Ahora me encontré con JSHint , una bifurcación de JSLint .
Entonces, me pregunto para las aplicaciones web, que se basan en gran medida en JavaScript, cuál es la mejor o más aplicable herramienta de validación para trabajar:
- ¿JSLint o JSHint?
Quiero decidir ahora sobre un mecanismo de validación y, en el futuro, utilizarlo para la validación del lado del cliente.
¿Y la diferencia entre jshint y jslint? Explique en un solo ejemplo de JavaScript.
Enlaces:
jshint - http://www.jshint.com/
jslint - http://jslint.com/
TL;DR
Utilice JSLint si está buscando un estándar muy alto para usted o su equipo, pero tenga en cuenta que no es necesariamente el estándar, sólo un estándar, algo del cual nos llega dogmáticamente de Doug Crockford.
Si desea ser un poco más flexible o tiene algunos viejos profesionales en su equipo que no creen en las opiniones de JSLint o van y vienen entre JavaScript y otros lenguajes de la familia C con regularidad, pruebe JSHint.
Versión completa
Dos artículos con el razonamiento detrás de la bifurcación explican por qué existe JSHint:
JSHint: una bifurcación de JSLint impulsada por la comunidad
Por qué bifurqué JSLint a JSHint
La idea detrás de JSLint es que está impulsado por la comunidad y no por Crockford. JSHint es generalmente más indulgente (o al menos configurable o agnóstico) en algunas opiniones estilísticas y sintácticas menores con las que JSLint es estricto.
Por ejemplo, si cree que tanto 1. como 2. a continuación están bien, o si desea escribir código con uno o más de los aspectos de 1. que no están disponibles en 2. , JSHint es para usted. Si cree que 2. es la única opción correcta, utilice JSLint. Estoy seguro de que hay otras diferencias, pero esto resalta algunas.
Pasa JSHint fuera de la caja - falla 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); } })();Pasa tanto JSHint como 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); } }());
El código JSLint me parece más atractivo visualmente. Las únicas características con las que no estoy de acuerdo son su odio hacia más de una vardeclaración en una función y las declaraciones de forbuclevar i = 0 , y algunas de las aplicaciones de espacios en blanco para las declaraciones de funciones.
Algunas de las cosas de espacios en blanco que JSLint aplica no son necesariamente malas, pero simplemente no están sincronizadas con algunas convenciones de espacios en blanco bastante estándar para otros lenguajes de la familia (C, Java, Python, etc.) que a menudo también se siguen como convenciones en Javascript. Dado que escribo en varios de estos idiomas a lo largo del día y trabajo con miembros del equipo a quienes no les gustan los espacios en blanco estilo Lint en nuestro código, encuentro que JSHint es un buen equilibrio. Detecta errores legítimos y código muy mal formado, pero no me ladra como lo hace JSLint (a veces, de maneras que no puedo desactivar) por las opiniones estilísticas o los detalles sintácticos que no me interesan.
Muchas bibliotecas buenas no son compatibles con Lint, lo que para mí demuestra que hay algo de verdad en la idea de que parte de JSLint se trata simplemente de impulsar una versión de "buen código" (que, de hecho, es un buen código). Pero, de nuevo, las mismas bibliotecas (u otras buenas) probablemente tampoco sean Hint'able, así que, touché.
[EDITAR]
Esta respuesta ha sido editada. Dejo la respuesta original a continuación para contextualizar (de lo contrario, los comentarios no tendrían sentido).
Cuando se formuló esta pregunta originalmente, JSLint era la principal herramienta de linting para JavaScript. JSHint era una nueva bifurcación de JSLint, pero aún no se había diferenciado mucho del original.
Desde entonces, JSLint ha permanecido bastante estático, mientras que JSHint ha cambiado mucho: ha descartado muchas de las reglas más antagónicas de JSLint, ha agregado una gran cantidad de reglas nuevas y, en general, se ha vuelto más flexible. Además, ahora está disponible otra herramienta, ESLint, que es aún más flexible y tiene más opciones de reglas.
En mi respuesta original, dije que no debes obligarte a cumplir con las reglas de JSLint; Siempre que comprenda por qué arroja una advertencia, podrá decidir por sí mismo si debe cambiar el código para resolver la advertencia o no.
Con el conjunto de reglas ultra estricto de JSLint de 2011, este fue un consejo razonable: he visto muy pocos conjuntos de códigos JavaScript que pudieran pasar una prueba de JSLint. Sin embargo, con las reglas más pragmáticas disponibles en las herramientas JSHint y ESLint actuales, es una propuesta mucho más realista intentar que su código pase a través de ellas sin advertencias.
Es posible que ocasionalmente haya casos en los que un linter se quejará de algo que usted hizo intencionalmente; por ejemplo, usted sabe que siempre debe usarlo, ===pero solo esta vez tiene una buena razón para usarlo ==. Pero incluso entonces, con ESLint tiene la opción de especificar eslint-disablealrededor de la línea en cuestión para que aún pueda pasar la prueba de pelusa sin advertencias, y el resto de su código obedezca la regla. (¡simplemente no hagas ese tipo de cosas con demasiada frecuencia!)
[SIGUE LA RESPUESTA ORIGINAL]
Por supuesto, utilice JSLint. Pero no te obsesiones con los resultados y con arreglar todo lo que advierte. Le ayudará a mejorar su código y le ayudará a encontrar errores potenciales, pero no todo lo que JSLint se queja resulta ser un problema real, así que no sienta que tiene que completar el proceso sin advertencias.
Prácticamente cualquier código Javascript con una longitud o complejidad significativa producirá advertencias en JSLint, sin importar qué tan bien escrito esté. Si no me cree, intente ejecutar algunas bibliotecas populares como JQuery a través de él.
Algunas advertencias de JSLint son más valiosas que otras: aprenda a cuáles debe prestar atención y cuáles son menos importantes. Se deben considerar todas las advertencias, pero no se sienta obligado a corregir su código para borrar cualquier advertencia determinada; está perfectamente bien mirar el código y decidir que estás satisfecho con él; Hay ocasiones en las que las cosas que a JSlint no le gustan son en realidad lo correcto.
Hay otro "reproductor" maduro y desarrollado activamente en el frente de linting de JavaScript ESLint:
ESLint es una herramienta para identificar e informar sobre patrones encontrados en el código ECMAScript/JavaScript. En muchos sentidos, es similar a JSLint y JSHint con algunas excepciones:
- ESLint usa Esprima para el análisis de JavaScript.
- ESLint utiliza un AST para evaluar patrones en el código.
- ESLint es completamente conectable, cada regla es un complemento y puedes agregar más en tiempo de ejecución.
Lo que realmente importa aquí es que se puede ampliar mediante complementos/reglas personalizados . Ya existen varios complementos escritos para diferentes propósitos. Entre otros , se encuentran:
- eslint-plugin-angular (aplica algunas de las pautas de la Guía de estilo angular de John Papa )
- complemento-eslint-jasmine
- complemento-eslint-backbone
Y, por supuesto, puede utilizar la herramienta de compilación que prefiera para ejecutar ESLint:
- gruñido-eslint
- trago-eslint
Tuve la misma pregunta hace un par de semanas y estaba evaluando tanto JSLint como JSHint.
Contrariamente a las respuestas a esta pregunta, mi conclusión no fue:
Por supuesto, utilice JSLint.
O:
Si busca un estándar muy alto para usted o su equipo, JSLint.
Como puedes configurar casi las mismas reglas en JSHint que en JSLint. Entonces yo diría que no hay mucha diferencia en las reglas que se pueden lograr.
Así pues, las razones para elegir uno u otro son más políticas que técnicas.
Finalmente decidimos utilizar JSHint por las siguientes razones:
- Parece ser más configurable que JSLint.
- Definitivamente parece más impulsado por la comunidad que un espectáculo de un solo hombre (no importa lo genial que sea The Man ).
- JSHint coincidía mejor con nuestro estilo de código OOTB que JSLint.
Haría una tercera sugerencia, Google Cierre Compilador (y también el Cierre Linter ). Puedes probarlo en línea aquí .
El compilador de cierre es una herramienta para hacer que la descarga y ejecución de JavaScript sea más rápida. Es un verdadero compilador de JavaScript. En lugar de compilar desde un lenguaje fuente a código máquina, compila desde JavaScript a un mejor JavaScript. Analiza su JavaScript, lo analiza, elimina el código inactivo y reescribe y minimiza lo que queda. También verifica la sintaxis, las referencias de variables y los tipos, y advierte sobre errores comunes de JavaScript.
