Dollar Sign Blues: Javascript et PHP

J'ai grandi en programmant C ++ et Java où tout était sûr et beau. Les compilateurs se sont assurés de me tenir au courant si jamais je m'égarais. Bien sûr, tout le monde a fait un peu de Perl à l'université, mais je n'ai pas inhalé. Les enfants de nos jours sont tous sur PHP sur le backend et Javascript sur le devant. En essayant d'être branché, je fais de même (pour le développement web). Le problème que je continue de rencontrer est que j'ajoute accidentellement un signe dollar ($) devant les variables régulières en Javascript et bien sûr personne ne dit rien parce que c'est la syntaxe légale souvent utilisée pour les objets jQuery.

Existe-t-il des outils de débogage ou des astuces de développement pour attraper cette confusion de signe dollar? Faites-vous souvent la même erreur et comment la traitez-vous émotionnellement? Les outils de développement Chrome ne voient pas toujours qu'il s'agit d'une erreur Javascript. J'utilise PhpStorm et Emacs pour le développement, mais ceux-ci n'attrapent pas ma stupidité, bien que je soupçonne qu'Emacs le fasse mais choisisse de ne pas m'en parler par dépit.

Si vous pensez que cette question est ridicule, je pense que vous avez raison. Mais nous vivons dans un monde où une variable a un signe dollar devant elle. Dans un tel monde, rien n'est ridicule.

Il n'y a rien de mal à utiliser des $variables dans. Je ne le ferais pas exprès sur chaque variable, mais c'est toujours une syntaxe valide. jQuery est l'un des exemples où $est utilisé comme nom de variable. C'est aussi pourquoi "les outils de développement Chrome ne voient pas toujours qu'il s'agit d'une erreur Javascript" , car il n'y a pas d'erreur en premier lieu.

Si vous avez peur d'écrire du code comme:

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

alors vous devez utiliser un vérificateur de style, comme jsLint , jsHint ou Google Closure Linter . Lequel de ceux-là? A vous de faire un choix. Pour vous aider, voici quelques notes:

Style

Google Closure Linter suit le guide de style JavaScript de Google , connu pour être intelligemment fait. L'utilisation d'un style bien connu pour JavaScript ou l'un des six autres langages est une bonne idée: lorsque vous partagez votre code ou embauchez un nouveau développeur, il est probable qu'ils connaissent déjà ce style.

De nombreux développeurs connaissent également le style de Douglas Crockford. Ce style est expliqué en détail dans JavaScript: The Good Parts , un livre qui vaut la peine d'être acheté par quiconque travaille avec JavaScript.

Quant à jsHint, je ne peux pas vraiment trouver quelles conventions sont utilisées, et le site Web lui-même semble éviter de parler de ce sujet. Peut-être que j'ai raté quelque chose.

Prise en charge par les IDE

JsLint et jsHint sont pris en charge par PhpStorm. C'est également le cas de Google Closure Linter.

Environnement

Google Closure Linter fait partie d'une série d'outils . Si vous utilisez déjà Google Closure Compiler ou Google Closure Library , il serait préférable de choisir Closure Linter plutôt que d'autres outils.

Rigueur

jsLint est connu pour être strict. jsHint est plus permissif, ce qui n'est pas toujours une bonne chose. Par exemple, l'une des raisons de bifurquer jsLint pour jsHint est expliquée dans un article qui montre un mauvais code qui produira une erreur dans jsLint, mais pas dans 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;
    }

    /* ... */
});

Le code est mauvais, car il semble que JavaScript ait une portée de bloc, alors qu'il ne l'a pas. Voir JavaScript: The Good Parts, p. 102, Annexe A: Pièces horribles, portée. En d'autres termes, en regardant le code sans connaître la langue, nous nous attendons nameà ne pas être visible en dehors de la boucle, alors qu'il restera visible.

Quant à Google Closure Linter, je pense qu'il se situe quelque part entre jsLint et jsHint, mais je n'ai pas assez d'informations pour le supporter.

Conclusion

J'éviterais jsHint: c'est trop permissif, ce qui signifie qu'il ne trouverait pas de bugs potentiels que les autres linters pourraient détecter. Le guide de style utilisé est difficile à trouver.

Chez jsLint et Google Closure Linter, le choix n'est pas évident. Les deux sont écrits par des experts, tous deux suivent un guide de style strict et bien décrit déjà suivi par des milliers de développeurs. Utilisez les deux pendant un certain temps, puis choisissez celui qui vous convient le mieux.