¿Cómo es que JQuery no pasa JSLint?

Question

Duplicar posible:
What good is JSLint if jQuery fails the validation

http://code.jquery.com/jquery-1.4.4.js

Ir a allí y pegarlo en www.jslint.com

No se supone que jQuery para ser válida. ...

Answer 1

Demasiado trabajo para cumplirlo Y cumplir con múltiples navegadores. JSLint es útil, pero es solo un analizador genérico. jQuery tiene buenas razones para cometer errores.

A veces solo necesitas simples hacks sucios para que el código funcione en los navegadores no compatibles.

vamos a ver uno por uno:

Problema en la línea 231 caracteres 20: esperaba '===' y en su lugar vio '=='.

return num == null?

Aquí jQuery utiliza == en null para comprobar si hay tanto undefined y null. Como jQuery se usa como una biblioteca externa, no puede garantizar si la entrada que pasamos a las funciones será undefined o null. Es más seguro para verificar ambos.

Hacer num === undefined || num === null para satisfacer a JSLint es ridículo.

Problema en la línea 446 caracteres 29: espera que una expresión condicional y lugar vio una asignación.

while ((fn = listo [i ++])) {

Aquí JSLint se queja de asignación en lugar de igual cheque. El motivo por el cual JSLint arroja este error es porque es común escribir = en lugar de == por error. La asignación en este ciclo while se realiza a propósito para hacer que el código sea más nítido.

Problema en la línea 550 caracteres 9: Vacío bloque.

var clave; para (clave en obj) {}
clave de retorno === indefinido || hasOwn.call (obj, clave);

JSLint se queja de un bloque vacío. Esto se ha hecho a propósito porque no queremos hacer nada con key, sino que queremos enumerar todas las claves y solo nos importa la última.

Problema en la línea 554 caracteres 15: Mover declaraciones var '' a la parte superior de la función .

para (nombre var en obj) {

JSLint insiste en que la declaración de variables en la parte superior de las funciones. Esto es un poco tonto y puede ser ignorado si lo desea. Es una cuestión de estilo.

Y luego el analizador se bloquea. Permítanme eliminar parte del código bloqueándolo y ver si puedo encontrar más quejas.

Problema en la línea 792 de caracteres 42: El '& &' subexpresión debe ser envuelto en parens.

ua.indexOf ("compatible") & rmozilla.exec (UA) ||

Estoy de acuerdo con esto (ua.indexO("compatile") < 0) && es mejor.

Problema en la línea 872 caracteres 3: Mover la invocación a los parens que contienen la función.

})();

Para cierres como:

(function() { 

})(); 
//}()); 

JSLint prefiere ver la invokion función en los soportes como una cuestión de estilo. También estoy de acuerdo con esto, pero realmente no importa en absoluto.

Problema en la línea 972 carácter 13: 'e' ya está definido.

} catch (e) {

Analizador se queja de la reutilización de las variables e En este caso sabemos que e sólo serán utilizadas en forma local en ese bloque de captura por lo que no importa si alteramos fuera el bloque de captura. Aquí me quedo con la legibilidad de volver a usar el nombre de la variable e

Problema en la línea 1097 caracteres 21: esperaba '===' y en su lugar vi '=='.

elem = elem == window?

Bien, me pillaste en esta.Estoy stumbed de por qué jQuery no utiliza === en window

Problema en la línea 1621 caracteres 24: espera que una tarea o función llamada y en su lugar vio una expresión.

parent.selectedIndex;

// Safari mis-reports the default selected property of an option 
// Accessing the parent's selectedIndex property fixes it 
if (name === "selected" && !jQuery.support.optSelected) { 
    var parent = elem.parentNode; 
if (parent) { 
    parent.selectedIndex; 

Aquí hay uno de esos errores compliancy entre navegadores que puede ser fijo, sino que causa el mal code

Problema en la línea 977 caracteres 17: Missing 'pausa' después de 'caso'.

caso "último":

JSLint dice que siempre debe romper después de que sus casos. Es perfectamente válido salir después de un caso. En la mayoría de los casos, se olvidó de break, pero aquí esto es intencional.

Problema en la línea 1099 caracteres 77: esperado una tarea o función llamada y en su lugar vio una expresión.

Array.prototype.slice.call ( document.documentElement.childNodes, 0 ) [0] ... .node

// Perform a simple check to determine if the browser is capable of 
// converting a NodeList to an array using builtin methods. 
// Also verifies that the returned array holds DOM nodes 
// (which is not the case in the Blackberry browser) 
try { 
    Array.prototype.slice.call(document.documentElement.childNodes, 0)[0].nodeType; 

La fuente aquí habla por sí mismo. Es una declaración extraña, pero si acceder a ella de esta manera arroja un error, puede ser atrapada. Todavía es válido, solo JSLint te dice "¿realmente quisiste hacer esto?"

Problema en la línea 2377 carácter 15: Malo en variable 'nombre'.

para (nombre en opciones) {

Aquí JSLint se queja de la utilización de name que puede entrar en conflicto con window.name en el ámbito global. Es una "palabra clave futura no del todo reservada, pero aún debe evitarse". Estuvimos en un cierre, así que es seguro.

Problema en la línea 2486 caracteres 29: Demasiado muchos errores. (60% escaneado).

La pila interna de JSLint no puede manejarlo. Voy a parar ahora.

Creo que el punto está ilustrado.

JSLint tiene un montón de "¿Estás seguro de que quieres hacer esto?" Y decían que sí, queremos hacer esto. Puede parecer un error pero no lo es.

Answer 2

Las reglas que jslint usa son guidelines, reglas no irrompibles. Hay muchas razones por las que es posible que desee ignorar algunas de ellas.

Hay bastantes detailed considerations of jslint rules por ahí; muchas personas no están de acuerdo con eso.

Personalmente, me gusta, pero use los comentarios en la parte superior de cada archivo JS para activar y desactivar varias advertencias cuando sé que lo que estoy haciendo es apropiado. Luego ejecutamos jslint contra todos nuestros JS como parte de las pruebas de CI y detecta algunos errores triviales de vez en cuando sin molestarnos en general.