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 !