Bonnes pratiques JavaScript [Débat]

**Community Management** · 17/05/2009, 11h18

Bonjour,

De par sa nature, JavaScript est plutôt mal loti concernant les bonnes pratiques de code.
L'apparition du "Web 2.0" a entrainé un regain d'intérêt pour ce langage, ainsi qu'une évolution notable de celui-ci.
Cependant, encore trop de codes obsolètes trainent sur la toile, codes souvent réalisés pour des versions anciennes des principaux navigateurs.
De plus, la syntaxe JavaScript est particulièrement permissive.
Tout cela implique que de trop nombreux débutants, se contentant de copier/coller des codes sans les comprendre, de même que par la suite, des développeurs confirmés continuent à utiliser des mauvais codes par habitude.

Je vous propose donc dans cette discussion d'indiquer ce que vous considérez comme la meilleure syntaxe JavaScript, que ce soit en terme de fonctions et méthodes à privilégier ou proscrire ou simplement en terme d'écriture du code.

A terme, le but est de collecter ces bonnes et mauvaises pratiques dans un article.

Nous vous demandons toutefois de respecter quelques règles élémentaires :

Ceci est un débat

Cela implique que des avis parfois contradictoires sont susceptibles d'apparaitre.
Il est donc impératif de rester courtois et de ne pas troller inutilement

Gardez à l'esprit qu'il faut savoir rester humble et que le fait d'avoir un avis ne fait pas de celui-ci une vérité absolue !

Pour chaque intervention

Donner son point de vue est une chose, l'expliquer et l'argumenter est encore mieux, merci donc d'expliquer au mieux les raisons de votre (vos) choix, cela permettra à la discussion d'être constructive et pédagogique.

Faites attention à ceux qui vous liront !

Il est important de bien rédiger ses interventions.
Certes, nous ne demandons pas que vous soyez dignes de l'académie française, mais prenez le temps de vous relire, de corriger vos fautes.
Le langage SMS, comme sur l'ensemble des forums est interdit.

Tout message ne respectant pas ces règles sera susceptible d'être supprimé à vue

à tous ceux qui participeront à cette discussion.

**Auteur** · 17/05/2009, 12h56

Pour commencer :

Toujours déclarer ses variables qu'elles soient locales ou globales :
Firefox est très sensible à ça et avec IE on peut avoir de mauvaises surprises ;
le nom de variables ne doit pas être un mot-clef JS ou l'id ou le name d'un élément ou le nom d'une balise (cf. le lien ci-dessus) ;
bannir innerHTML pour inclure dans la page des nouveaux éléments (div, input, table, etc.). Utiliser le DOM ;
bannir document.write()
dans les balises HTML écrire le nom des événements en minuscules (sinon ça ne passe pas la validation W3C) ;

Ensuite en ce qui me concerne, j'évite les méthodes getAttribute() et setAttribute(). Au lieu d'utiliser setAttribute(), je préfère écrire :

element.style.attribut = "valeur";

au moins tous les navigateurs reconnaissent cette syntaxe.

J'évite également addEventListener() et attachEvent() (les navigateurs reconnaissent soit l'une soit l'autre fonction), je préfère cette écriture :

element.onevent = function(){mafonction()};

**bigboomshakala** · 17/05/2009, 17h15

côté événement

Envoyé par Auteur

J'évite également addEventListener() et attachEvent() (les navigateurs reconnaissent soit l'une soit l'autre fonction), je préfère cette écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

element.onevent = function(){mafonction()};

cette écriture suffit dans bien des cas. mais la limite est qu'on ne peut poser qu'un callback sur l'événement.

Je préfère faire ma propre petite fonction crossbrowser permettant d'enregistrer/supprimer les callback. Quelque chose comme ça pour l'enregistrement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
function addHandler(element, type, callback){
  if (element.attachEvent){
    element.attachEvent("on" + type, callback);
  }
  else{
    element.addEventListener(type, callback, false);
  }
}
 
addHandler(element, "click", maFonction);

dans la forme
- toujours mettre les accolades, même si le bloc de code ne comporte qu'une instruction (voire la fonction addHandler ci-dessus). ça améliore la lisibilité et évite de tomber dans un piège.
- toujours indenter impeccablement son code. encore une histoire de lisibilité et de maintenance facilitée.

**le_chomeur** · 17/05/2009, 20h47

jusque la je suis totalement d'accord avec auteur sauf pour les évènement ou je rejoint BBS pour une gestion des évènements attachEvent ou addEventListener ce qui permet de rendre le code d'une compatible et de deux, non intrusif , ce qui veut dire que quelques soit la page ou vous ajouterez le script , il n'interfèrera pas avec ceux déjà en place.

**Auteur** · 18/05/2009, 00h35

Bon j'avoue que le code ci-dessous est un peu de la provocation

car je vois rarement ce genre de chose (contrairement à ce que j'ai évoqué plus haut).

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
<div>
	<input type="button" value="cliquez ici" onclick="
        var sp, el;
        
        el = document.getElementById('monDiv');
        sp = document.getElementById('idSpan');
        el.style.display='block';
        sp.style.visibility='hidden';
 
        var affiche = new Function('sp','sp.style.visibility = \'visible\'');   
        setTimeout(function(){affiche(sp)},'2000')" />
</div>
 
<div id="monDiv" style="display:none">
	<span> bla bla bla bla bla bla bla bla</span><br/>
	<span id="idSpan"> bla bla bla bla bla bla bla bla</span><br/>
	<span> bla bla bla bla bla bla bla bla</span><br/>
 
</div>

Le code est fonctionnel...

Il s'agit simplement de dire qu'il faut limiter la quantité de javascript dans les balises HTML

**SpaceFrog** · 18/05/2009, 09h32

Pas grand chose à ajouter aux remarques faites ci-dessus, si ce n'est vous faire part d'un methode qui me donne entière satisfaction jusqu'à présent:

Coder en w3c correct pour Firefox, puis patcher les deux ou trois bugs que vous aurez pour IE.

Privilégiez le cloneNode et la gestion par les rows tant que vous le pouvez.

**le_chomeur** · 18/05/2009, 09h55

tant qu'on est dans les bonnes pratiques

et qu'on se concentre sur le débat, pour ou contre le développement objet en javascript ??

De mon coté je ne code plus que comme ça !

- Gain de lisibilité
- Réutilisation du code beaucoup plus simple

**Bovino** · 18/05/2009, 21h08

Pour ma part :

Concernant la forme

* Prévoir une version des scripts pour les tests et une pour la prod.
La version test comprendra :
- Les commentaires : commenter son code est essentiel pour pouvoir en assurer la maintenance et être compréhensible par toute personne ayant à travailler sur le script ; les commentaires doivent être mis à jour en même temps que le code (modifier une fonction sans modifier les commentaires peut amener à une mauvaise compréhension ultérieure).
- L'indentation : bien indenter son code le rend plus facilement lisible. Ma règle est la suivante : les accolades de fonction / boucle suivent la déclaration ; le retour à la ligne suivant aura une tabulation en plus ; l'accolade fermante se met après retour à la ligne et retrait d'une tabulation.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function ma_fonction(){
    var variable1, variable2;
    for(var i=0; i<longueur; i++){
        //corps de la boucle
    }
    // autres instructions
}

Pour être sûr de ne pas oublier la fermeture, j'ouvre et ferme immédiatement mes accolades, je fais deux retours chariots, je remonte d'une ligne, je mets une tabulation puis je code.
La version de prod :
Une fois le code terminé ou les modifications effectuées et le code testé, on peut le compacter (suppression des commentaires, retours chariot etc.) pour mise en prod.

* Choisir des noms de variables / fonctions / paramètres explicites.

* Toujours déclarer les variables en début de fonction.

* Si une variable doit conserver son type, faire précéder son nom par l'initiale du type (ex : sMa_chaine ; iMon_entier ...). Cela permet de se rendre compte facilement si l'on a changé un type intentionnellement ou non.

* Faire une déclaration de variable par type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var sMa_chaine1, sMa_chaine2, sMa_chaine3;
var aTableau1, aTableau2, aTableau3;

* Déclarer les variables globales dans un objet. Cela évite d'éventuels conflits dans le cas de scripts multiples par exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
GNavigation = {
    iChaine: 'Chaine de caractères',
    tTableau: un_tableau
}
function affiche(){
    alert(GNavigation.iChaine);
}

* Toujours utiliser les point-virgules et les parenthèses, même lorsque cela peut être omis. En cas de modification du code, cela peut éviter les mauvaises surprises !
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if(a==b)
    alert(a);

qui pourrait devenir facilement si l'on doit aussi afficher b par la suite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if(a==b)
    alert(a);
    // ajout ultérieur :
    alert(b);  //malheureusement, cette instruction n'est plus dans la condition !

Concernant le fond

* Bien se demander si le code utilisé correspond à une syntaxe actuelle (adapté aux navigateurs courants...)

* Concernant les événements, en règle générale (sauf éventuellement pour le onload du body), un élément HTML n'aura qu'un comportement pour un événement donné, je me rangerait donc à la syntaxe du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
elementHTML.onevenement = function(){
    // corps de la fonction
}

à noter que je préconise de passer systématiquement par une fonction anonyme (voir ci-après).

* Pour les timers, callbacks ou autre, passer systématiquement par une fonction anonyme plutôt que par le nom de fonction (donc pas de paramètre possible) ou pire, une chaîne de caractères.

* Proscrire absolument eval().
Il est à noter que eval() et ses dérivés (ceci explique les préconisations précédentes) est probablement ce qu'il y a de pire dans JavaScript, pour s'en persuader, il faut être conscient que la grande majorité des failles de sécurité de JavaScript sont dues à des utilisations de eval() et/ou ses dérivés (setTimeout, setInterval, write() et toutes les méthodes évaluant un texte). Voir à ce sujet le cas de l'attaque Samy sur myspace.com.

* Pour les fonctions récurrentes et/ou non cross-browser, se faire une bibliothèque de fonctions utilitaires. L'exemple le plus courant étant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
function $(un_id){
    return document.getElementById(un_id);
}

Cette bibliothèque de fonction pourra par ailleurs être définie dans l'objet des variables globales !

* Concernant le développement objet en JavaScript, je dirais (comme un Normand) que ça dépend de ce que l'on fait. Pour ajouter quelques fonctionnalités minimes sur un site, cela me semble lourd pour pas grand chose. Sur des projets de plus grande envergure, je pense au contraire que cela va dans l'esprit du langage.
Donc pour simplifier, non s'il s'agit juste de mettre une couleur de police sur un champ de formulaire erroné, mais un grand oui pour de plus grosses applis type web service par exemple.

Voilà pour le moment

je tiens toutefois à noter pour être honnête que je ne suis pas toujours le premier à appliquer ces principes...

EDIT :

Envoyé par le_chomeur

je rejoint BBS pour une gestion des évènements attachEvent ou addEventListener ce qui permet de rendre le code d'une compatible et de deux, non intrusif

Désolé, mais je ne vois pas en quoi des syntaxes du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

element.onevent = ...

peut être considéré comme du code intrusif... il est bien destiné à être utilisé dans du code externe, donc en dehors des attributs HTML

**SpaceFrog** · 18/05/2009, 22h34

Beef ...

* Faire une déclaration de variable par type :

sans doute juste pour retrouver ses petits ?
Le variable n'étant pas typées e, js je ne vois pas ce que cela peut apporter de plus ?

aux parenthèses j'ajouterais les {}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if(a==b){ alert(a); }

même si il n'y a qu'une ligne ...

**le_chomeur** · 19/05/2009, 10h22

Envoyé par Bovino

Pour ma part :
EDIT :

Désolé, mais je ne vois pas en quoi des syntaxes du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

element.onevent = ...

peut être considéré comme du code intrusif... il est bien destiné à être utilisé dans du code externe, donc en dehors des attributs HTML

en affectant une méthode directement sur l'évènement , tu interfères avec les actions déja en place , ou futures

**franculo_caoulene** · 19/05/2009, 12h52

Certaines des remarques qui suivent ne sont valables que pour des documents (X)HTML.

Je mets le code Javascript en fin de document, pour une question de performance et d'amélioration progressive.
Je déclare les variables avec le mot clé var, en tête de bloc, avec un nom verbeux et un "type" défini par affectation. Je privilégie le français. Le nom d'un tableau se finira par un "s", un booléen commencera par "a" ou "est". Je déclare les variables en tête de bloc et non de fonction, car ça m'ennuie de déclarer une variable qui ne sera peut-être jamais utilisée. Les objets commencent par une majuscule.
J'utilise toujours les accolades et les parenthèses, mais ne vais pas toujours à la ligne.
Pour les boucles for, je déclare un "imax" dans l'instruction. Si, à chaque boucle, on compare l'incrément à la taille d'un tableau celle-ci sera calculée à chaque fois. Il y a donc baisse de performance.
Je privilégie les notations littérales. C'est plus court et plus lisible à force.
Je privilégie la délégation d'évènements pour les documents fortement interactifs. Cela permet de ne pas se prendre la tête à savoir si l'élément qu'on supprime contient ou non un évènement. Sinon, une simple association de fonction à la propriété évènement suffit (obj.onclick = function(){};)
J'utilise constamment la programmation orientée objet, ça permet notamment de bénéficier d'espaces de nom. Je n'étends pas les objets Javascript ou DOM avec des fonctions personnalisées, c'est pour ça que je n'aime pas prototype. J'utiliserai ces fonctions dans mon espace de nom.
Je privilégie l'utilisation de === plutôt que == pour les tests. Cela permet de tester le type aussi.
"Eval is evil" comme tout le monde sait.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
var FC = {// 5, 7)
  DOM: {
    getElementsByClassName: function(classe, noeud, balise) {
      var elements = [];// 2)
      if (document.getElementsByClassName) { elements = document.getElementsByClassName(classe); }
      else {
        if (noeud === undefined || noeud === null) { noeud = document; }// 3, 8)
        if (balise === undefined || balise === null) { balise = "*"; }
        var elementsAParcourir = noeud.getElementsByTagName(balise);// 2)
        var pattern = new RegExp("(^|\\s)" + classe + "(\\s|$)");
        for (var i = 0, imax = elementsAParcourir.length; i < imax; i++) {
          if (pattern.test(elementsAParcourir[i].className)) { elements.push(elementsAParcourir[i]); }
        }
      }
      return elements;
    }
  },
  Evenement: {
    ajouter: function(elm, evt, fn) {
      if (document.addEventListener) {
        if (elm.nodeType===1 || elm.nodeType===9) { // 8)
          elm.addEventListener(evt, function(e) {
            if (!fn(e)) { e.preventDefault(); }
          }, false);
        } else {
          for (var i = 0, imax = elm.length; i < imax; i++) {// 4)
            elm[i].addEventListener(evt, function(e) {
              if (!fn(e)) { e.preventDefault(); }
            }, false);
          }
        }
      } else if (document.attachEvent) {
        if (elm.nodeType===1 || elm.nodeType===9) {
          var r = elm.attachEvent("on" + evt, fn);
          return r;
        } else {
          for (var i = 0, imax = elm.length; i < imax; i++) {
            var r = elm[i].attachEvent("on" + evt, fn);
            return r;
          }
        }
      }
    }
  }
};
FC.Evenement.ajouter(document, "click", function(e) {// 6, 7)
  var elm = e.target || event.srcElement;
  if (elm.className.indexOf("div")==-1) {
    var elms = FC.DOM.getElementsByClassName("div");
    for (var i=0, imax=elms.length;i<imax;i++) {
      elms[i].style.display="none";
    }
  }
});

Il y a certainement plein d'autres choses à dire.

**le_chomeur** · 19/05/2009, 13h12

peux tu expliquer un peu plus le "===" au niveau des tests, sur les type ? ( et condition booléan )

**franculo_caoulene** · 19/05/2009, 13h14

9 == '9' retourne true
9 === '9' retourne false

**Bovino** · 19/05/2009, 13h26

Envoyé par SpaceFrog

sans doute juste pour retrouver ses petits ?
Le variable n'étant pas typées e, js je ne vois pas ce que cela peut apporter de plus ?

oui, c'est un peu ça...
En fait, dans l'esprit, c'est surtout lorsque je dois créer de nouvelles variables, je peux voir facilement celles qui sont déjà déclarées

Sinon, le fait que les variables ne soient pas typées peut être utile mais uniquement quand on sait exactement ce que l'on fait. Donc avoir des variables dont on défini le type quelles doivent avoir permet de repérer les erreurs, que ce soit dans le code ou dans la conception.

@le_chomeur :
Arf, oui, je ne voyais pas intrusif dans ce sens là. Pour moi, du code intrusif est du code qui ne respecte pas le principe de séparation information/mise en page/comportement. Dans ton cas, j'aurais plutôt appelé ça du code exclusif

**le_chomeur** · 19/05/2009, 15h45

Merci franculo_caoulene
Bovino ;-)

Dite ce serais pas mal d'en faire un petit article non ? ( non je ne m'y colle pas lol )

**RomainVALERI** · 19/05/2009, 15h51

Envoyé par franculo_caoulene

1) Je mets le code Javascript en fin de document, pour une question de performance et d'amélioration progressive.
[...]
2) Je privilégie les notations littérales. C'est plus court et plus lisible à force.

1) Je n'ai pas compris ce que tu veux dire

>>> entre deux balises script en fin de body plutot que dans le head, c'est ca ?

En ce qui me concerne, et comme d'autres, je n'ai toujours qu'un UNIQUE "point d'entrée" javascript, constitué par un appel de script externe dans le head de ma page, lequel ne comporte qu'UNE seule ligne exécutable directement (donc en dehors des définitions de fonctions dans lesquelles se passe en fait tout le reste) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
window.ecouter('load', initialisation);

où "ecouter" est une petite fonction crossbrowser attachEvent/addEventListener (comme évoqué plus haut), et "initialiser" est la fonction venant (entre autres taches éventuelles) appliquer tous les gestionnaires d'événement aux éléments de la page qui doivent être associés à un comportement (donc classiquement : du "non-obstrusive js" comme d'autres l'ont aussi fait remarquer, avec plus ou moins de tolérance ou de rigueur)

2) Tu veux parler de l'utilisation de littéraux comme 42, "choucroute", ou encore "function() { ... }" ?

Plus court et plus lisible que quoi ?

Envoyé par Bovino

1) Déclarer les variables globales dans un objet. Cela évite d'éventuels conflits dans le cas de scripts multiples

2) à noter que je préconise de passer systématiquement par une fonction anonyme (voir ci-après).

* Pour les timers, callbacks ou autre, passer systématiquement par une fonction anonyme plutôt que par le nom de fonction (donc pas de paramètre possible) ou pire, une chaîne de caractères

3) Proscrire absolument eval()

1) Ca, ça me plait beaucoup

Je prends

2) Heu... que veux-tu éviter en contraignant volontairement l'utilisation de paramètres à ce niveau ?

3) Nous sommes bien d'accord

Cependant je ne vois pas le lien (je veux dire : je ne le vois pas encore

) entre eval et ceux que tu désignes comme ses dérivés, je pense notamment à setTimeOut ou setInterval...

___________________________________________

Dernière chose, à propos des commentaires : je suis un "commentateur fou" repenti

: c'est-à-dire que j'ai eu tendance à en abuser, mais j'ai aujourd'hui une politique qui me plait bien et qui m'a l'air assez efficace : je mets toujours des commentaires détaillés et précis, mais je ne mélange plus code et commentaires : les com, c'est juste au-dessus de la signature de la fonction, et si la fonction est particulièrement longue ou complexe, j'insère à un ou deux endroits un "bloc" de commentaires, bien distinct de ce qui suit et précède, pour donner les informations nécessaires. Il n'y a d'ailleurs bien sur que des connaissances "métier" dans ces commentaires, c'est-à-dire des choix arbitraires d'implémentation, voire une explicitation de la logique applicative si elle est difficile à deviner, qui sont réellement utiles en commentaire, pas des conseils javascript pour débutants du type "j'incrémente la valeur de i"

)

**franculo_caoulene** · 19/05/2009, 16h15

Oui je mets tout le code Javascript juste avant </body>. Ça permet d'afficher le document (X)HTML statique mise en forme d'abord, puis de l'améliorer en ajouter la couche "comportement ".

Quand je parle des littéraux, je parle en effet des syntaxes {}, [], etc. C'est plus court et plus lisible que new Object(), new Array(), new RegExp(), etc.

Je peux aussi ajouter :
10) détecter l'existence d'objets plutôt que de tester le navigateur cf. le test document.getElementsByClassName, par exemple, dans le code précédemment posté.

**RomainVALERI** · 19/05/2009, 16h24

Envoyé par franculo_caoulene

Je peux aussi ajouter :
10) détecter l'existence d'objets plutôt que de tester le navigateur cf. le test document.getElementsByClassName, par exemple, dans le code précédemment posté.

Oui, je suis assez d'accord, j'évite également le test sur la chaine contenue dans navigator.userAgent

Et quand c'est possible, j'ai tendance à utiliser de préférence l'opérateur in, par exemple :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if (propriete in Objet) { ... }

**franculo_caoulene** · 19/05/2009, 16h30

Avec l'opérateur in on teste si une chaîne correspondant à une propriété est dans un objet.
Le fait de passer par une chaîne ne me plaît pas, il doit y avoir interprétation quelque part, donc lenteur. On en revient au point 8) de mon post initial. Je préfère tester (noeud === undefined) plutôt que (noeud == "undefined").

**RomainVALERI** · 19/05/2009, 16h40

Envoyé par franculo_caoulene

Je préfère tester (noeud === undefined) plutôt que (noeud == "undefined").

Sur ce point, tout-à-fait d'accord...

Par contre, j'avoue que je prends rarement en compte les préoccupations de performance dont tu parles (par inexpérience probablement

, et parce que je crois dur comme fer au fameux "early optimization is the root of all evil" ^^)
Quand j'aurai de gros projets nécessitant ce genre de considérations, je ne resterai pas borné sur mes positions et je prendrai en compte la "lenteur" de certaines instructions...

Bonnes pratiques JavaScript [Débat]

JavaScript

Discussions similaires

Partager

Partager