Discussion :

[Community Management]

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]

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]

c�t� �v�nement

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]

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]

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]

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.

[kernelfailure]

. . .
bannir document.write()
. . .

Ca fait plusieurs fois que je lis que certains expriment le d�sir de ne plus utiliser cette m�thode sans bien comprendre leur motivation.

Pourquoi tant de haine ?

. . .
Ah oui, pour la notation hongroise, pr�fixer par le type est inutile ou presque un tr�s bon article qui explique le malentendu de cette notation Joel on software

Je comprends mieux pourquoi aujourd'hui encore je trouve inutile l'emploie de ui32Machin ou LPTRBidule etc... La belle affaire d'avoir ce genre d'information, surtout ici, pour du javascript.
En revanche, l'aspect originel est plut�t int�ressant. C'est bien dommage que cette notion, cette vraie utilit�, ait �t� mal comprise et d�grad�e.

J'ai toujours trouv� ce 'typage' p�nible, et je trouve �a particuli�rement ridicule et inadapt� � la programmation objet.
Simple : il faudrait inventer autant de type que d'objets.
Or la tendance est de n'accorder de l'int�r�t que pour les types basiques (limit� sous JS), ce qui devient un tour de force sous Python (O� tout est objet).

. . .
On peut penser que la variable "iModeSearchSelected" indique l'ID du mode de recherche actuellement s�lectionn�.
. . .

Justement, un simple "idSearchMode" (pour identifiant de mode de recherche) ou "usrSearchMode" (pour mode de recherche de l'utilisateur - donc s�lectionn�) seraient beaucoup plus parlant.
Ou pourquoi pas "idxSearchMode" s'il s'agit d'un index (selected).
Le fait que la valeur soit stipul�e comme enti�re n'est pas d'un grand int�r�t.
D'ailleurs, le nom est bien plus important, "searchMode" plut�t que "modeSearch"

Mais 'i' pour 'integer' ou 'instance' ?
Oui, parce que j'ai d�j� vu des 'o' pour qualifier des instances...
Donc, 'var oI = new Integer();' tandis que 'var iI = 0;' ne serait pas pareil.

Tout n'est pas noir ou blanc, et dans le genre, je trouve plut�t bien de fortement qualifier les param�tres de m�thodes et fonctions, par exemple, en nommant clairement le type d'instance attendu, genre 'dateDeparture' ou 'instanceUser' ou 'amtBooking' ou 'amountBooking'.
Mais je pr�f�re lire 'amount' que 'float' ou 'fAmount' ou 'fAmt'...

[Oscar Hiboux]

J'ai toujours trouv� ce 'typage' p�nible, et je trouve �a particuli�rement ridicule et inadapt� � la programmation objet.
Simple : il faudrait inventer autant de type que d'objets.

Je dirais plus : "ridicule et inadapt�" surtout aux langages � types forts o� il est impossible de se tromper sinon �a ne compile m�me pas. D'ailleurs, pour ces langages, tout bon IDE reconnait le types des entit�s manipul�es et les colore et pr�sente de bien belles mani�res. Pour les autres �a pourrait se comprendre, quand l'�quipe au complet est rigoureuse (ce qui n'arrive que tr�s tr�s rarement). Donc inadapt� ? Assez souvent, du fait du temps d'adaptation � la pratique lorsqu'un membre int�gre une �quipe et au temps perdu par l'incompr�hension passag�re d� au mauvais emploi de ces petits pr�fixes et la diminution de lisibilit� du code assez rapidement.
Je me souviens avoir vu passer des "xDog" dans certains projets employant ce genre de pr�fixes pour signifier qu'on manipulait un noeud XML... �a peut conduire loin ! (P.S. : j'aimais bien l'id�e, ahah)

[...]"idSearchMode" (pour identifiant de mode de recherche) ou "usrSearchMode" (pour mode de recherche de l'utilisateur - donc s�lectionn�) seraient beaucoup plus parlant.
Ou pourquoi pas "idxSearchMode" s'il s'agit d'un index (selected).
Le fait que la valeur soit stipul�e comme enti�re n'est pas d'un grand int�r�t.

Hmm, "idSearchMode" conviendrait mieux � "mode de recherche d'identifiant", non ?
"usrSearchMode" ? Pourquoi s'�corcher les yeux et ne pas �crire pleinement "userSearchMode" ? Pareil, "idxSearchMode" ? "searchModeIndex", non ? �a sert � quoi d'�conomiser 2 caract�res pour sacrifier la lisibilit� ?

[...]je trouve plut�t bien de fortement qualifier les param�tres de m�thodes et fonctions, par exemple, en nommant clairement le type d'instance attendu, genre 'dateDeparture' ou 'instanceUser' ou 'amtBooking' ou 'amountBooking'.

Allez, dans la s�rie... "dateDeparture", c'est le d�part de la date ? "instanceUser" L'utilisateur-instance ? L'utilisateur de l'instance ? "amtBooking" ? Ah, on �conomise 3 caract�res, hihi.

D'ailleurs, le nom est bien plus important, "searchMode" plut�t que "modeSearch"

En effet, ahah !

[...]je trouve plut�t bien de fortement qualifier les param�tres de m�thodes et fonctions, par exemple, en nommant clairement le type d'instance attendu, genre 'dateDeparture' ou 'instanceUser' ou 'amtBooking' ou 'amountBooking'.

Pour ma part, ce que je n'aime pas trop dans ce genre de pratique c'est que �a "pollue" les noms de symboles, et je trouve tellement confortable de pouvoir r�utiliser une m�me variable pour accueillir deux objets de type diff�rents au fil des instructions... A�e, pas taper !

[kernelfailure]

�a sert � quoi d'�conomiser 2 caract�res pour sacrifier la lisibilit� ?

Arf... On peut se poser la question.
C'est parce qu'hongrois que c'est mieux
Mais attention � l'exc�s inverse, o� les noms sont des romans.

"instanceUser" L'utilisateur-instance ? L'utilisateur de l'instance ?

Tout simplement une instance de la classe User

Pour ma part, ce que je n'aime pas trop dans ce genre de pratique c'est que �a "pollue" les noms de symboles, et je trouve tellement confortable de pouvoir r�utiliser une m�me variable pour accueillir deux objets de type diff�rents au fil des instructions... A�e, pas taper !

M�me pas besoin de caster en plus ! La mega classe !!!
C'est un confort que j'emploie tr�s souvent lorsque la port�e est locale et/ou la dur�e de vie est courte.
Mixed est un type tr�s puissant. Le polymorphisme absolu : Tout est Object.

[Oscar Hiboux]

M�me pas besoin de caster en plus ! La mega classe !!!

Ahahah, trop la classe, oui !!

Bien d'accord avec le reste aussi, c'est exactement ce que je fais. ^^

[RomainVALERI]

• bannir document.write()

Tiens j'ai repens� � �a aujourd'hui...

>>> hop.
(a la limite c'est presque dommage de ne pas avoir claqu� tout �a dans un eval pour rigoler)

[Eric2a]

Salut,

Oui je sais RomainVALERI... document.write c'est mauvais.

J'ai ajouter un code utilisant le DOM.

[RomainVALERI]

Salut,

Oui je sais RomainVALERI... document.write c'est mauvais.

J'ai ajouter un code utilisant le DOM.

Oui oui, ce n'est pas vraiment ton intervention qui est en question, hein

J'ai surtout �t� �ffray� par le titre du post et puis en voyant le code de la demande...
(et m�me, de toutes fa�ons, si le code avait �t� "propre" techniquement parlant, quand quelqu'un demande de l'aide pour afficher de la publicit�, j'avoue que je passe habituellement mon chemin )

[Coocky10]

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

Pourquoi bannir innerHTML ?

[sdamart]

Pourquoi bannir innerHTML ?

Ce n'est pas innerHTML qu'il faut bannir mais document.write car il s'agit je pense d'une m�thode qui t'oblige � r��crire le contenu de ta page. Et aujourd'hui ce n'est plus ce que l'on cherche � faire.
Pour la citation de auteur,
Certaine personne �crivent cela :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

document.getElementById("el").innerHTML="<div id=\"autre_el\">POP</div>";

Il n'y a rien � dire dans cette ligne de code j'ajoute une DIV dans #el d�finitivement
Mais �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
document.getElementById("el").innerHTML="<div id=\"autre_el\">POP<a href=\"#\" id=\"closer\">x</a></div>";
document.getElementById("closer").onClick=function(){ //Je ne tiens pas compte des event_caller IE et FireFox (c'est pour l'exemple)
document.getElementById("autre_el").remove();
return false;
};

C'est maladroit est bancal

[NoSmoking]

Ce n'est pas innerHTML qu'il faut bannir mais document.write...

peut �tre pas bannir mais a utiliser en connaissance de code et de fa�on coh�rente.

Pour test et pour ce rendre compte des effets de bord : http://www.developpez.net/forums/d97...l/#post5463783.

[hefeust]

bonjour � tous !

mon point de vue sur les javascript est qu'avant, on se contentait de coller ("scotcher") des petits bouts de script sur la page HTML, tels des post-its sur un paperboard. Dor�navant, la bonne approche est de consid�rer le JS comme formant une application � part enti�re et qui utilise la page et le DOM comme son entr�e/sortie (ou du moins son effet de bord) principal.

Bien s�r me direz vous elle �change �galement avec le clavier et la souris, avec divers �v�nements, et avec le serveur via XHR, mais pensez app toute faite comme le sont certains clients de mail bien connus, ou les jeux vid�o qui fleurissent un peu partout.

Ainsi on peut appliquer des principes comme le MVC ou le MVR pour faire son d�veloppement.

Voil� pour la th�orie . Pour la pratique cela se complique un peu. Ca manque cruellement de tutoriels bien faits et en ligne (sur d�veloppez peut �tre ?) et j'ai l'impression que toutes mes recherches en direction d'une doc construite me renvoient syst�matiquement sur la page de tel ou tel �diteur anglophone qui vend un bouquin...

Donc j'attends avec impatience un ou des tutos sur ce site mais il faudra y trouver :
- bootstrap de l'appli et structure de fichiers sous jacent
- module pattern, include/import de fichiers
- utiliser correctement les closures
- les donn�es comment les g�rer et les d�coupler au maximumu de la manip de DOM pour la Vue
- concevoir des widgets en interactions les uns avec les autres et/ou avec le serveur

Voil�, � vos stylos et claviers , les auteurs, je ne manquerai pas de vous lire...

PS : J'ai remarqu� quand m�me depuis quelques temps des biblioth�ques qui sortent du lot (exemple : CraftyJS, Quintus... pour les jeux) qui ne cherchent plus syst�matiquement � �crire des classes (Java, PHP, C++) pour faire de l'h�ritage, mais qui fonctionnent plutot en "share" (partage) de composants. Cela me semble plus proche de la philosophie de JavaScript (partage de prototype)

on a donc une approche 'partage' (has-A) de javascript (== horizontal) qui oblige � se changer l'esprit par rapport � l'h�ritage (de qualit�s mais aussi de d�fauts...) "is-A" (== vertical) qu'on pratiquait avant ... tiens c'estr �tonnant, c'est ce qu'on fait dans les r�seaux sociaux, le partage...

en attendant les tutoriels (bis) merci et bonne journ�e !