"var" n'est pas obsolète, mais c'est tout comme

En JavaScript, le mot-clé var était un mal nécessaire, avant 2015. C'était le seul mot-clé à utiliser pour restreindre la portée des variables. La norme ES2015 (ou ES6) a introduit par la suite const et let, qui sont aujourd'hui beaucoup plus logiques, tellement que cela rend var quasiment inutile.

C'est que rédiger du JavaScript avec var permettait des non-sens. Par exemple, écrire x=2;var x; dans une fonction n'était pas grave, l'interpréteur se devait alors de scanner le code pour relever les var avant le l'exécuter. Donc écrire ça ou var x;x=2; ou x=2;var x;, ça revenait au même.

Pire encore, on pouvait mettre des var à l'intérieur des if, for, ou n'importe quoi d'autre, puis les utiliser à l'extérieur de ceux-ci. La variable était déclarée à l'intérieur de la fonction qui l'utilise. Ainsi, dans l'exemple suivant :

function test() {
    b = 1;
    if (condition) {
        var b = 3;
        console.log(b);
    }
    console.log(b);
}

Que var soit avant b = 1 ou avant b = 3 ne change rien. C'est au programmeur de penser que, pour que son code soit facilement compréhensible par le collègue, il devrait mettre le mot-clé var à l'extérieur du if.

D'ailleurs, il m'arrivait souvent à l'époque, pour m'assurer que les variables étaient détruites en sortant du if, de les mettre dans une fonction auto-exécutée. Ça s'en vient un brin complexe!

function test() {
    var b=1;
    if (condition) {
        (function(){
            var b=3;
            console.log(b);
        })();
    }
    console.log(b);
}

Bref, en bon québécois, var, c'est de la marde.

const et let à la rescousse

Ces deux mots-clés règlent beaucoup de problèmes. Premièrement, on va les distinguer : const signifie que la variable initialisée ne sera pas réassignée par la suite. Il est donc impossible d'écrire seulement const chose; sans l'assigner. L'idée est surtout de s'assurer que la variable (qui devient une constante par le fait même) n'est assignée qu'à un seul endroit. Au contraire, une variable déclarée avec let peut être réassignée plus loin dans le code. Dans les deux cas, la portée de la variable n'est pas à l'intérieur d'une fonction, mais à l'intérieur d'un bloc de code. Un bloc de code, c'est tout ce qui est délimité par des accolades : on parle de l'intérieur d'une fonction, mais aussi de l'intérieur d'un if, d'un for, d'un while... Ainsi, dans cet exemple :

function test() {
    const b=1;
    if (condition) {
       const b=3;
       console.log(b);
    }
    console.log(b);
}

Il y a deux variables b distinctes dans cette fonction. Celle qui vaut 3 disparaît en sortant du if. Celle qui vaut 1 devient inaccessible à l'intérieur du if à cause du même nom utilisé pour la variable qui vaut 3.

const est particulièrement utile pour assigner une variable à un objet; on peut quand même assigner les propriétés de l'objet, tant qu'on ne réassigne pas la variable, tout va. Ainsi, const f=document.forms[0]; f.href='/post-it'; est du code correct.

Dans un contexte de développement intensif, on s'aperçoit qu'on aura plus souvent besoin de const que de let. En effet, il arrive moins souvent qu'on ait à assigner la même variable plus d'une fois.

let sert souvent pour les compteurs de boucle.

for(let x = 0; x < 10; x++) {
    console.log(x);
}

Alors que JavaScript tolère plusieurs var d'une même variable dans une fonction, il ne tolérera pas plusieurs let dans le même bloc de code.

function () {
    let aa = 1;
    console.log(a);
    let aa = 2; // SyntaxError!
    console.log(a);
}

Rien n'empêche de faire des blocs de code libres, par contre. Par exemple :

function () {
    {
        let aa = 1;
        console.log(a);
    }
    let aa = 2; // Tout baigne!
    console.log(a);
}

Voyant ce que permettent let et const, on ne peut que se rendre à l'évidence que var devient archaïque. Pourquoi n'est-il pas encore marqué d'obsolescence officiellement? Ché pas...

Éviter le mot-clé « this »

Le mot-clé this1 est un raccourci parfois utile lorsqu'on écrit du nouveau code JavaScript. Ce mot-clé a cependant la particularité de se comporter différemment du this en C, C++ ou Java. Il se comporte même différemment selon la version JavaScript ou même si on est en mode strict ou pas. C'est  […]

Lire la suite

jQuery doit mourir

Ok, le titre est un peu exagéré. Mais jQuery est devenu somme toute une tare dans la programmation JavaScript. Aujourd'hui, utiliser jQuery retarde l'apprentissage du JavaScript. jQuery demande le chargement d'une bibliothèque de plus de 200 kibioctets, ce qui peut paraître léger pour un ordinateur  […]

Lire la suite

La beauté de la combinaison de addEventListener() et closest()

Pour remplacer la méthode jQuery.on(), ou son ancêtre jQuery.live(), qui permettent d'attacher un événement virtuellement à des éléments qui n'existent pas encore au moment de l'appel, ces deux méthodes sont très utiles. EventTarget.addEventListener() existe depuis longtemps. En fait, c'est Internet  […]

Lire la suite

Javacript - La suppression des événements avec removeEventListener() au lieu de $.off()

L'affaire qui se passe, c'est que $(el).on() ne fait pas seulement la même chose que el.addEventListener(). $(el).on() enregistre aussi l'événement dans une liste d'événements d'un certain type (ex:'click') pour que si jamais on fasse $.off() sur le même type d'événement, ça puisse les effacer. Une  […]

Lire la suite

Pourquoi ce blogue

Je suis programmeur informatique depuis 1995. Développeur web depuis 2005. J'ai passé par plusieurs langages: Foxpro, Assembleur, Clipper, VisualBasic, ASP... et depuis maintenant 15 ans LAMP (Linux-Apache-MySQL-PHP). Et le javascript s'est insidieusement imposé dans mon bagage de connaissances - tu  […]

Lire la suite

Haut de page