Bonnes pratiques JavaScript

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

:merci: � tous ceux qui participeront � cette discussion.

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() :aie: :bug:
• 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 :

Citation:

---

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 :

Citation:

---

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

---

c�t� �v�nement

Citation:

---

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:

---

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:

---

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.

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.

Bon j'avoue que le code ci-dessous est un peu de la provocation :oops: car je vois rarement ce genre de chose (contrairement � ce que j'ai �voqu� plus haut).

Code:

---

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 ;)

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.

tant qu'on est dans les bonnes pratiques :ange: 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

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:

---

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:

---

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:

---

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:

---

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

---

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

Code:

---

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:

---

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:

---

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 :aie: je tiens toutefois � noter pour �tre honn�te que je ne suis pas toujours le premier � appliquer ces principes... :(

EDIT :

Citation:

---

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:

---

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 :?

Beef ...

Citation:

---

* 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:

---

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

---

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

Citation:

---

Envoy� par Bovino

Pour ma part :
EDIT :

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

Code:

---

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 :)

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

1. Je mets le code Javascript en fin de document, pour une question de performance et d'am�lioration progressive.
2. 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.
3. J'utilise toujours les accolades et les parenth�ses, mais ne vais pas toujours � la ligne.
4. 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.
5. Je privil�gie les notations litt�rales. C'est plus court et plus lisible � force.
6. 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(){};)
7. 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.
8. Je privil�gie l'utilisation de === plut�t que == pour les tests. Cela permet de tester le type aussi.
9. "Eval is evil" comme tout le monde sait.

Code:

---

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.

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

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

Citation:

---

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 ?

---

:mouarf: 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 :aie:

Merci franculo_caoulene
Bovino ;-)

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

Citation:

---

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:

---

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 ?

Citation:

---

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 :mrgreen: Je prends 8-)

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

3) Nous sommes bien d'accord :mrgreen:
Cependant je ne vois pas le lien (je veux dire : je ne le vois pas encore :aie:) 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 :aie: : 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" :aie:)

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�.

Citation:

---

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:

---

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

---

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").

Citation:

---

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 :aie:, 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...