¿Cómo reducir la frecuencia de tales errores en mi código?

Question

Tome un vistazo a this JsFiddle:

var requests = [ 
    $.ajax("http://search.twitter.com/search.json", { data: { q: 'ashishnjain' }, dataType: 'jsonp' }) 
    .done(function() {console.log("request");}), 

    $.ajax("http://search.twitter.com/search.json", { data: { q: 'ashishnjain' }, dataType: 'jsonp' }) 
    .done(function() {console.log("request");}) 
]; 

$.when(requests).done(console.log("alldone")); 

El resultado esperado es: request request alldone, pero en realidad esto imprime alldone request request.

En realidad, hay dos errores en este código (lo dejo como ejercicio si disfrutas de ese tipo de cosas), pero finalmente creo que esto ocurre porque JavaScript y jQuery son extremadamente indulgentes cuando se dan argumentos que no tienen sentido alguno. En este entorno, lo "correcto" parece ser "hacer algo o nada, ¡simplemente no arrojar un error!".

En vista de que este código pasa JSLint, y sólo me ha costado un par de horas de depuración (el código real era, por supuesto, algunos órdenes de magnitud más complejo), me pregunto qué más puedo hacer para reducir el tiempo perdido en tal indulgencia injustificada. Este no es un ejemplo aislado; parece suceder una y otra vez ¿Alguna sugerencia?

Answer 1

parece que confundió

$.when([x,y]) 

para

$.when(x,y) 

No creo que hay una herramienta de análisis por ahí que le ayudará a atrapar a este tipo de error, ya que es perfectamente aceptable para pasar una lista para cuando. Si usted quiere tener una función más restrictiva puede hacer uno mismo:

function whenForMoreThanOne(list_of_deferreds){ 
    return $.when.apply($, list_of_deferreds); 
} 

Answer 2

Es realidad, es posible check types en tiempo de ejecución en Javascript, es sólo que ser estricto no es el estilo preferido en Javascript. A los hackers de JS les gusta colgarlo.

Otros hackers lidian con esto, ¿no? Entonces, en lugar de echarle la culpa al lenguaje o jQuery por sus largas horas dedicadas a la depuración de este problema, sugeriría en cambio que investigue otras formas de reducir sus esfuerzos de depuración.

Aquí hay un par de sugerencias que se me ocurre:

1. prueba a cabo pequeñas piezas de código en la consola interactiva JS primero antes de pegarlo en el archivo .js: este
   • que permite rápidamente iterar hasta que salga bien (¿Cómo se utiliza .cuando $()?)
   • asegura que cuando no se hace bien, a comprender cómo utilizar la API de
2. Mantenga espárrago ying JS, y sigue escribiendo más. El segundo error que cometió: no envolvió console.log ("todo listo") en una función, muestra que un concepto fundamental sobre JS aún no se ha establecido completamente en su lugar: un hacker experimentado de JS nunca cometería ese error.

Answer 3

En el caso de su error más prominente, la respuesta puede decirse en dos palabras: static typing. La tipificación estática no resuelve todos los problemas, pero genera una gran parte del trabajo que implica rastrear estos fallos sutiles.

Las desventajas de los tipos estáticos son no, como reclamos missingno, tienen algo que ver con hacer la programación más difícil o menos poderosa o algo por el estilo. El mayor problema es que la fuerza del sistema de tipeo de un idioma parece variar inversamente con la popularidad del idioma. Los lenguajes tipeados muy bien tipados como Scala y Haskell aún se encuentran en el nivel boutique de aceptación. Java es mucho más popular, pero su sistema de tipos es difícil de usar y está lleno de agujeros; algo similar se puede decir de C#. El sistema de tipos del PHP inmensamente popular golpearía a un observador neutral como un sabotaje deliberado. Los lenguajes antiguos como FORTAN y C ni siquiera lo intentan.

No sé por qué ocurre esto, pero estoy convencido de que la explicación obvia - a las personas no les gusta el tipado fuerte - no es correcta.

Un problema relacionado es que aún no puede compilar cualquier lenguaje fuertemente tipado con JavaScript. El enfoque más cercano es probablemente GWT.