Dollar Sign Blues: Javascript y PHP


18

Crecí programando C ++ y Java donde todo era seguro y hermoso. Los compiladores se aseguraron de mantenerme bajo control si alguna vez me extraviaba. Por supuesto, todos hicieron un poco de Perl en la universidad, pero yo no inhalé. Los niños en estos días tienen que ver con PHP en el backend y Javascript en el frente. Al tratar de ser moderno, hago lo mismo (para el desarrollo web). El problema con el que me encuentro constantemente es que accidentalmente agrego un signo de dólar ($) delante de las variables regulares en Javascript y, por supuesto, nadie dice nada porque esa es la sintaxis legal que a menudo se usa para los objetos jQuery.

¿Hay alguna herramienta de depuración o trucos de desarrollo para captar esta confusión de signos de dólar? ¿Cometes a menudo el mismo error y cómo lo enfrentas emocionalmente? Las herramientas de desarrollo de Chrome no siempre ven que se trata de un error de Javascript. Uso PhpStorm y Emacs para el desarrollo, pero esos no captan mi estupidez, aunque sospecho que Emacs sí, pero decide no hablarme de eso por despecho.

Si crees que esta pregunta es ridícula, creo que tienes razón. Pero vivimos en un mundo donde una variable tiene un signo de dólar frente a ella. En un mundo así, nada es ridículo.


2
Emocionalmente? Solo ataca a tus colegas.
Chris Schiffhauer

@ChrisSchiffhauer Lamentablemente, trabajo en una academia donde el aislamiento es el nombre del juego. Tendría que programar una reunión con un colega para durar, y eso eliminaría la espontaneidad de todo.
Alan Turing

Respuestas:


11

No hay nada de malo en usar $en variables. No lo haría a propósito en todas las variables, pero sigue siendo una sintaxis válida. jQuery es uno de los ejemplos donde $se usa como nombre de variable. Esa es también la razón por la cual "las herramientas de desarrollo de Chrome no siempre ven que esto es un error de Javascript" , porque no hay ningún error en primer lugar.

Si tienes miedo de escribir código como:

var demo = function demo() {
    var a = 123;
    ...
    $a = 456; // A new variable is created in global scope.
}

entonces debe usar un verificador de estilo, como jsLint , jsHint o Google Closure Linter . Cual de esos? Depende de usted hacer una elección. Para ayudarlo con eso, aquí hay algunas notas:

Estilo

Google Closure Linter sigue la Guía de estilo de JavaScript de Google , que se sabe que se hace de manera inteligente. Usar un estilo conocido para JavaScript o cualquiera de los otros seis idiomas es una buena idea: cuando comparte su código o contrata a un nuevo desarrollador, es probable que ya estén familiarizados con este estilo.

Muchos desarrolladores también están familiarizados con el estilo Douglas Crockford. Este estilo se explica en detalle en JavaScript: The Good Parts , un libro que vale la pena comprar por cualquiera que trabaje con JavaScript.

En cuanto a jsHint, realmente no puedo encontrar qué convenciones se usan, y el sitio web en sí parece evitar hablar sobre ese tema. Tal vez me perdí algo.

Apoyo de IDEs

Tanto jsLint como jsHint son compatibles con PhpStorm. Este es también el caso de Google Closure Linter.

Ambiente

Google Closure Linter es una de una serie de herramientas . Si ya está utilizando Google Closure Compiler o Google Closure Library , sería preferible elegir Closure Linter sobre otras herramientas.

Rigor

Se sabe que jsLint es estricto. jsHint es más permisivo, lo que no siempre es bueno. Por ejemplo, una de las razones para bifurcar jsLint para jsHint se explica en un artículo que muestra un código incorrecto que producirá un error en jsLint, pero no en jsHint:

/*global jQuery */

// Example taken from jQuery 1.4.2 source
jQuery.extend({
    /* ... */

    isEmptyObject: function( obj ) {
        for ( var name in obj ) {
            return false;
        }
        return true;
    }

    /* ... */
});

El código es malo, porque parece que JavaScript tiene un alcance de bloque, mientras que no lo tiene. Ver JavaScript: The Good Parts, pág. 102, Apéndice A: Partes horribles, alcance. En otras palabras, al mirar el código sin conocer el idioma, esperamos nameno ser visibles fuera del bucle, mientras permanezca visible.

En cuanto a Google Closure Linter, creo que está en algún punto intermedio entre jsLint y jsHint, pero no tengo suficiente información para respaldar eso.

Conclusión

Evitaría jsHint: es demasiado permisivo, lo que significa que no encontrará errores potenciales que los otros linters detectarían. La guía de estilo que se utiliza es difícil de encontrar.

Entre jsLint y Google Closure Linter, la elección no es obvia. Ambos están escritos por expertos, ambos siguen una guía de estilo estricta y bien descrita ya seguida por miles de desarrolladores. Use ambos por algún tiempo, luego elija uno que sea más práctico para usted.


+1: me ganó. Comencé a soltar mis puntos y comas cuando cambio los idiomas de F # a C #, así que puedo compartir su dolor;)
scrwtp

2
Solo una nota, ya que OP está utilizando PhpStorm: tanto JSLint como JSHint están integrados y se pueden configurar para inspeccionar su código a pedido o incluso sobre la marcha. Errores como el de su ejemplo son bastante fáciles de detectar.
yannis
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.