Logo JavaScript

Messages JSLint – Move ‘var’ declarations to the top of the function.

Flattr this!

Je démarre cette série avec le message

Move ‘var’ declarations to the top of the function.

Cause

Prenons un exemple de code :

function demo () {
    if(true) {
        var toto = true;
    }
}

Le problème ici est de ne pas avoir déclaré la variable au bon endroit.

La solution

En JavaScript, la portée d'une variable correspond au scope. Et celui-ci s'étend sur tout le corps de la fonction.

Le code correct aurait été d'écrire ceci :

function demo () {
    var toto;
    if(true) {
        toto = true;
    }
}

Masquer cette erreur et donc l'ignorer peut gêner dans la lisibilité du code si vous déclarez vos variables n'importe où. Tout déclarer en tête de fonction permet donc de rendre le code lisible.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://www.jerome-lauriol.fr Jerôme

    Y a -t-il ne implication sur la gestion mémoire ?
    En déclarant les variable dès le début du scope le moteur javascript peut réserver des blocs contiguës. Est-ce que cela joue ?

    • Djordje Lukic

      Non, ca ne joue pas car meme si tu definis une variable quelque part dans le corps de ta fonction elle sera definie des le debut de la fonction.
      Plus precisement :

      function foo() {
      console.log(bar);
      /* code code code */
      var bar = 'asd'f;
      return 42;
      }

      Ne lancera pas d’erreur car cette fonction est equivalente (du point de vue du moteur JavaScript) a :

      function foo() {
      var bar;
      console.log(bar);
      /* code code code */
      bar = 'asd'f;
      return 42;
      }

      C’est ce qu’on appel « hoisting ». Un bon atricle dessus se trouve ici.

      (j’espere que les balises html passent…)

      • http://www.mathieurobin.com/ Mathieu

        (à priori ça passe)

        Je crois qu’on ne peut pas faire plus complet et précis comme réponse.

      • http://www.jerome-lauriol.fr Jerôme

        Je trouve quand même bizarre les différences de performances sur plusieurs navigateurs avec une déclaration en tête de fonction, ou dans le corps du code. ( jsperf )
        (même si je constate un gain de temps énorme lors de l’écriture du code, en évitant les erreurs de déclaration)

        • http://www.mathieurobin.com/ Mathieu

          C’est normal. Dans le cas de l’affectation à posteriori (avec déclaration en tête), il fera deux opérations quand il n’en fait qu’une dans le cas de l’affectation au moment du besoin.

  • Djordje Lukic

    Salut,

    Pour moi ça n’a rien a voir avec la lisibilité du code mais plutôt et surtout sur le scope de la variable qui s’étend, comme tu le dis, à la fonction. Ça serait donc plus pour éviter les confusions des gens qui viennent des langages qui ont un block scope (le C par exemple).

    Je ne sais pas toi mais je ne vais jamais définir « var i; » au début de ma fonction juste pour pouvoir faire une boucle for, je vais plutôt écrire « for(var i = 0; ….) ».

    De manière générale je préfère définir au début de la fonction les variables qui contiennent quelque chose, « var emitter = new Emitter; » par exemple et définir les autres quand j’en ai besoin, « var item = items[i]; » dans une boucle par exemple.

    Le tout est de comprendre comment fonctionne le scope et le hoisting des variables en js pour ne pas avoir de problèmes.

    • http://www.mathieurobin.com/ Mathieu

      C’est plus ou moins les deux à priori, Douglas explique (ici : http://javascript.crockford.com/code.html, Variable declarations)
      « JavaScript does not have block scope, so defining variables in blocks can confuse programmers who are experienced with other C family languages. Define all variables at the top of the function. »
      Et
      « doing so makes the program easier to read and makes it easier to detect undeclared variables ».
      Même si c’est plus proche de ton point de vue.

      De façon générale, je suis plutôt de l’avis de Douglas, je déclare sans aucune exception toute mes variables locales en début de fonction, y compris les index de parcours de boucle. D’ailleurs j’ai tendance à ne pas les appeler i mais plutôt index_parcours_nomDuTableauOuObjetParcouru.
      Je travaille sous PhpStorm, comme tout bon IDE, il me propose une auto-complétion relativement efficace donc pas de problème du fait de la longueur du nom de la variable et ce n’est pas gênant à l’exécution puisque après minification, bah c’est minifié…

Articles liés