¿De qué sirve JSLint si jQuery falla la validación

? He estado explorando diferentes métodos para limpiar y probar mi JavaScript. Pensé que al igual que en cualquier otro idioma, una forma de mejorar es leer un buen código. jQuery es muy popular, por lo que debe tener un cierto grado de buena codificación.¿De qué sirve JSLint si jQuery falla la validación

Entonces, ¿cuando corro jQuery través de la validación de JSLint me da este mensaje:

Error:

Problem at line 18 character 5: Expected an identifier and instead saw 'undefined' (a reserved word).

undefined,

Problem at line 24 character 27: Missing semicolon.

jQuery = window.jQuery = window.$ = function(selector, context) {

Problem at line 24 character 28: Expected an identifier and instead saw '='.

jQuery = window.jQuery = window.$ = function(selector, context) {

Problem at line 24 character 28: Stopping, unable to continue. (0% scanned).

Esto se hizo utilizando JSLint y jquery-1.3.1.js

Fuente

2009-02-02 Bobby Borszich

+10

jQuery no es precisamente ejemplar Javascript – singpolyma

Sé que esto es una cuestión de edad, pero jQuery utiliza JSLint ahora: http://docs.jquery.com/JQuery_Core_Style_Guidelines –

104

JSLint pone a prueba las opiniones de una persona en particular (Douglas Crockford) con respecto a lo que hace buen código de JavaScript. Crockford es muy bueno, pero algunas de sus opiniones son, en el mejor de los casos, retentivas a nivel anal, como la regla de subrayado o el uso de operadores de incremento/decremento.

Muchos de los problemas etiquetados por JSLint en el resultado anterior son problemas que Crockford considera que dificultan el mantenimiento del código, o son cosas que él cree que le han llevado a hacer cosas "inteligentes" en el pasado que pueden ser difícil de mantener

Hay algunas cosas que Crockford identifica como errores con los que estoy de acuerdo, como el punto y coma faltante. Dejar caer el punto y coma obliga al navegador a adivinar dónde insertar el token del final de la declaración, y que a veces puede ser peligroso (siempre es más lento). Y varios de esos errores están relacionados con JSLint no esperando o admitiendo asignaciones múltiples como jQuery en la línea 24.

Si tiene una pregunta sobre un error JSLint, envíe un correo electrónico a Crockford, él es muy bueno respondiendo, y con su respuesta, al menos sabrá por qué se implementó JSLint de esa manera.

Ah, y solo porque una biblioteca es popular no significa que su código sea bueno. JQuery es popular porque es una biblioteca relativamente rápida y fácil de usar. Que esté bien implementado es bastante intrascendente para su popularidad entre muchos. Sin embargo, seguramente debería leer más código, todos deberíamos.

JSLint puede ser muy útil para identificar problemas con el código, incluso si JQuery no supera los estándares que desea.

Fuente

2009-02-02 22:55:27 foxxtrot

bien todos los puntos tomados, y bueno señalar que doesn populares 't igual bueno –

JQery en realidad trata de ser compatible jslint ahora! Mire aquí -> http://forum.jquery.com/topic/jquery-1-4-2-jslint-report –

A Crockford no le gusta poner declaraciones if/for/while, etc en una línea. Él siempre quiere ver {} llaves. ¿Alguien puede aclarar por qué esto importa? (La legibilidad no es una respuesta aceptable). –

JSLint lo ayuda a detectar problemas, no es una prueba de validez o un reemplazo para pensar. jQuery está bastante avanzado a medida que js va, lo que hace que este resultado sea comprensible. Quiero decir que las primeras líneas son hacks de velocidad, no es de extrañar que el analizador js más rígido tenga un par de errores.

En cualquier caso, la suposición de que el código popular es el código perfectamente correcto o incluso "bueno" es defectuoso. El código de JQuery es bueno, y puedes aprender mucho al leerlo. Debería ejecutar sus cosas a través de JSLint, aunque solo sea porque es bueno escuchar otra opinión sobre lo que ha escrito.

De la descripción de JSLint:

JSLint takes a JavaScript source and scans it. If it finds a problem, it returns a message describing the problem and an approximate location within the source. The problem is not necessarily a syntax error, although it often is. JSLint looks at some style conventions as well as structural problems. It does not prove that your program is correct. It just provides another set of eyes to help spot problems.

JSLint defines a professional subset of JavaScript, a stricter language than that defined by Edition 3 of the ECMAScript Language Specification. The subset is related to recommendations found in Code Conventions for the JavaScript Programming Language.

Fuente

2009-02-02 22:56:38 jacobangel

gran explicación - buena adición de enlace del sitio JSLint –

Si usted no está desarrollando activamente jQuery sí, ¿por qué incluso correr JSLint sobre ella en absoluto? Si funciona, funciona, y no tienes que preocuparte por eso.

Fuente

2009-02-02 22:57:38 nickf

Entiendo lo que dices, pero ¿cómo podría explicarse? así ayuda a nuestros codificadores –

Es de esperar que la gente piense en lo que es relevante y en lo que no vale la pena pasar el tiempo preocupándose? – nickf

Se requiere pasar jQuery a JSLint para evitar errores "no definidos" en su propio código. – HRJ

Los objetivos de los desarrolladores de jQuery no son los mismos que sus objetivos. jQuery está diseñado para la velocidad y la compacidad y lograr esos objetivos supera la legibilidad y la facilidad de mantenimiento.

Las pruebas de Crockford en JSLint tienen más que ver con lograr algo en lo que se sentiría cómodo llevándose a su casa para conocer a su madre, lo cual es una preocupación válida si va a estar casado con su código por algún tiempo.

Fuente

2009-02-03 15:55:26 Prestaul

El propósito de JSLint se afirma claramente en el FAQ [1]:.

"JSLint define un subconjunto profesional de JavaScript, un lenguaje más estricto que el definido por Edición 3 de la especificación del lenguaje ECMAScript El subconjunto está relacionada a las recomendaciones que se encuentran en las Convenciones de Código para el Lenguaje de Programación de JavaScript ".

Ahora bien, si usted está confundido: ECMA3 ya es un subconjunto de las capacidades de JS proporcionados por cualquier de los actuales JS intérpretes (véase [2] para una descripción de la relación entre las versiones JavasScript y ECMAScript)

Para responder a la pregunta "de qué sirve JSlint": * use JsLint para verificar que está utilizando un subconjunto "seguro" de Javascript que es poco probable que se rompa entre las implementaciones de JS. * utilizar JSLint para verificar seguido las convenciones de código Crockford [4]

Fuente

2009-02-13 10:54:25 oberhamsi

"jQuery es muy popular por lo que debe tener un cierto grado de buena codificación".

Nos gustaría esperar que este sea el caso con jQuery, pero desafortunadamente no es realmente cierto. jQuery es útil y popular, pero no es una biblioteca de JavaScript bien escrita. David Mark publicó recientemente una crítica mordaz de jQuery en comp.lang.javascript que examina un gran número de ejemplos de código pobre encontré en jQuery:

http://groups.google.com/group/comp.lang.javascript/msg/37cb11852d7ca75c?hl=en&

Fuente

2009-03-02 04:39:37 vsedach

+43

Acabo de leer todo el hilo, y aprendí que David Mark es un idiota, jQuery apesta, todas las bibliotecas JS apestan, cualquier cosa que no escribas es una mierda, e incluso si lo escribes, todavía apesta. Lo que no encontré fueron alternativas a jQuery, o realmente ninguna sugerencia útil en absoluto. jQuery es –

"Alternativas a jQuery"? Depende de lo que quieras usar si es para. jQuery tiene tantas funciones, nada bueno las tendrá todas. Las libs pequeñas tienen pequeños conjuntos de funciones para que pueda usar las que necesita. – singpolyma

Al parecer, el que se supone que debe aspirar menos es http://forkjavascript.org/ Voy a probarlo para mi próximo proyecto. – vsedach

he encontrado un caso en que es muy JSLint , muy útil: cuando tomas una de esas geniales bibliotecas que flotan alrededor de la 'Red, luego otra, luego otra, pronto te encuentras cargando 50k de Javascript en cada carga de página nueva (el almacenamiento en caché puede ayudar, pero no es una solución de panacea).

¿Qué harías entonces? Comprima esas bibliotecas. ¡Pero su host no hace compresión para archivos que no sean html! ¿Y qué? Usas un compresor Javascript.

Lo mejor que he encontrado es Dean Edward's; Lo usé para comprimir Showdown de John Fraser (un Markdown para la biblioteca Javascript), pero desafortunadamente, la compresión rompió el código. Como Showdown ya no es compatible, tuve que corregirlo yo mismo, y JSlint fue invaluable para eso.

En resumen, JSlint es útil para preparar su código JS para la compresión de trabajo pesado.

Fuente

2009-11-13 09:08:26

Cualquier compresor JS que valga la pena en estos días crea un árbol de símbolos abstracto y, por lo tanto, puede realizar los cambios de código necesarios para comprimir correctamente el código, siempre que no tenga el código realmente roto. – foxxtrot

-1

Si le gusta los métodos de conexión en cadena como lo hace jQuery, puede agradecerle a YUI3.

Fuente

2009-12-06 15:04:53

-1

JQuery, por supuesto, no es lo mejor del mundo. Eso ya está claro cuando miras la notación. La combinación del paréntesis del dólar es realmente mala para tus ojos. La programación debe ser clara y simple. JQuery está lejos de eso. Esa razón es suficiente para que yo no la use.Que no está escrito correctamente no me sorprende y solo subraya mis pensamientos en esta biblioteca de JavaScript.

Fuente

2010-08-24 13:41:22 mike

-1 Porque no estoy de acuerdo con casi todo el monto de esta publicación –

¿De qué sirve JSLint si jQuery falla la validación

Respuesta

Cuestiones relacionadas