Discussion :

[kimjoa]

comme quelqu'un la dit, c'est un débat alors débattons

je vais vous exposer mes bonnes pratiques ! enfin même si j'ai parfois tendance à pas toujours les mettre en œuvre , celle-ci peuvent bien sur être différentes des votres

1 - indenter votre code, on voit tout de suite les différents bloque , et rend le tout plus simple à comprendre
2 - déclarer toujours vos variables, au début de chaque bloques
3 - utiliser des fonctions anonyme pour encapsuler des variables privées partagées par plusieurs fonctions
4 - Étendre les classes native sauf Object , (vais me faire taper sur les doigts ) , beaucoup pense qu'il ne faut pas , car elles peuvent rentré en collision avec d'autre scripts, c'est pour cela qu'il faut étendre que des fonctions qui ne sont pas implémenté par certain navigateurs (par exemple forEach), ou dont le fonctionnement est relativement certain (trim, isEmail, bind)
5 - Utiliser des noms de variables le plus explicite que possible, et en anglais
6 - Commenter votre code (en anglais si possible)
7 - Limiter les variables globales
8 - Utiliser l'objet tant que c'est possible, cela permet une meilleur maintenance, et ca permet l'héritage
9 - Utiliser le DOM quand on doit créer des objets dynamiquement (en fonction de variables) ou sinon innerHTML si on en connait ses limites
10 - Utiliser eval que lorsque cela n'est pas possible sans, par exemple, compilation de fonction dans un contexte précis , retour ajax
11 - Utiliser les gestionnaire d'évènement
12 - Utiliser un loader de script avec gestion des dépendances (pourquoi mettre tout le js dans l'index alors que les 4/5 doivent servir dans des modifications DOM via ajax)
13 - Utiliser votre librairie perso, ou mettre les mains dans le cambouis d'une autre pour n'utiliser que le code nécessaire
14 - Utiliser l'évènement domcontentloaded, ou une fonction similaire (genre jquery ready)(note : je sais pas si le faite de placer un script en fin de page permet l'exécution de celui-ci avant la fin du chargement des images , sinon c'est équivalent)
15 - Utiliser les sprites css, mais ceux, que pour les images utilisé, et non celles qui peuvent être utilisées
16 - Ne pas forcement vouloir absolument respecter les standards, ceux -ci ne sont pas des règles de programmation, mais des recommandations, mais quand même savoir les prendre en comptes

bon doit en manquer quand même

bye

[sekaijin]

pour ma part
voici ce que je fais
1) Une seule variable globale App (un objet) c'est lui qui porte des membre des variable de mon application.
2) Aucune fonction je ne déclare que des méthodes dans mes classes ou objets. un fonction "globale" à mon application et une méthode de App
3) toujours utiliser le DOM
4) Ne jamais hésité à surcharger les objet du dom pour leur faire porter de de nouvelles méthodes et membres (attention je ne modifie pas le prototype des objet du DOM je ne sais même pas si c'est possible sur tout les navigateur)
5) surcharge des classes standards pour ajouter des méthodes standard par exemple

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
/**
* @class Array
*/
Ext.applyIf(Array.prototype, {
    /**
    * Return the last object in array
    * @return {Object}|null The objec in the array (or null if is empty)
    */
    top : function(){
        if (0 == this.length){
            return null;
        }
        return this[this.length -1];
    }
});

qui permet alors d'utiliser les tableau comme des piles avec push pop et top
6) ne jamais générer de code javascript par un serveur dynamique php par exemple tout mon code js et statique donc compilé et gardé en cache par le navigateur ce qui améliore grandement les perfs
7) utiliser xml pour les échange avec le serveur (là j'aimerais le faire systématiquement, mais j'utilise aussi JSON lorsque JSON sera supporté nativement par tous les navigateur je pense que je changerais cette règle) xmlhttprequest le parse nativement
8) pas d'échange de HTML avec le serveur
9) pas de texte à afficher autre que les donnée échangé avec le serveur. pour les messages d'erreurs, titre nom de bouton libellé de champs etc. j'utilise un nom de clef Mon appli en fonction de la lange choisit charge un fichier statique JSON de langue qui contient tout ce qu'il faut. l'or d'un échange la clef fourni par le serveur sert à piocher le bon message
10) aucune référence quelle qu'elle soit à une base de donnée. l'appli js appelle des services sur le serveur et c'est lui qui maitrise le métier.
11) séparer les couches. j'utilise MVC j'ai donc des vues qui ne contiennent que de l'IHM. des contrôleurs qui orchestrent la dynamique de l'application. et des modèles qui sont en fait des stub au sens RMI en gros des objets servant à appeler le service correspondant sur le serveur.

après pour le reste c'est comme pour tout dev indenter nom de méthode explicite idem pour les membres. j'utilise les java codding rules (les classes on une Majuscule sur chaque mot, les variable commence par une minuscule et sont des nom avec complément, les méthodes commence par une minuscule et sont des verbe avec complément décrivant les paramètres etc.)
j'utilise javadoc pour documenter mon code
A+JYT

[madevilts]

Vos avis sont très interessant. De mon coté, je développe principalement des applications métiers contenant énormément d'évènements et interactions sur les pages donc je suis plus dans la logique d'optimisation IE (vu que c'est le navigateur standard chez nous).

Voici mes quelques règles:
1. Le globale tout en majuscule MAGLOBALEAMOI
2. Les objets commencent par des majuscules : MonObjetAMoi
3. Les fonctions contiennent des majuscules mais commencent par une minuscule : maFonctionAMoi
4. Variables tout en minuscule : mavariableamoi
5. Eviter au maximum les document.getElement... et proscrire les fonctions du genre :

Code :

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

function $(monId) { document.getElementById(monId); }

Mettre dans un tableau les pointeurs vers les objets DOM utilisés souvent.
6. Eviter au maximum d'utiliser xxxx.length dans les boucles.
7. Lorsqu'on parcourt un tableau à beaucoup de dimension, créer une variable temporaire pour travailler sur une dimension spécifique.
8. Limiter au maximum les échanges avec le DOM. Préférer .innerHTML quand c'est possible, même si c'est dégueulasse, c'est bien plus rapide.
9. Indentation obligatoire.
10. Documentation en tête de fonction du type Javadoc avec typage des paramètres etc...
11. Utiliser la conditionnelle en une ligne pour les conditions simples :

Code :

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

resultat = (z==1)?'x':'y';

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

[laurentg2003]

tout a fait d'accord avec les différents posts
sauf pour une chose
plutôt que if(mavar== "undefined")
je prefere if(undefined==mavar)
c'est une proriété js et donc pas de string et donc un gain de performance et en cas d'erreur de syntaxe genre (mavar="undefined")
le script généra une erreur direct

[Willpower]

tout a fait d'accord avec les différents posts
sauf pour une chose
plutôt que if(mavar== "undefined")
je prefere if(undefined==mavar)
c'est une proriété js et donc pas de string et donc un gain de performance et en cas d'erreur de syntaxe genre (mavar="undefined")
le script généra une erreur direct

Ca dépendra de la nature de l'objet à tester je dirai.

Dans bien des cas,

Code :

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

if(obj=="undefined")

renverra "false" même si l'objet est undefined (il faudrait faire : if(typeof obj=="undefined") pour obtenir un "true"), il est donc évident qu'il vaut mieux utiliser la propriété undefined plutot qu'un string.

par contre si on sait d'avance que la nature de notre obj devrait être de type "Object object" par exemple(enfin, n'importe quoi sauf un booleen et un entier qui pourraient valoir 0 ou false), il est plus simple (et plus rapide*) de tester

Code :

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

if(!obj)

.

*plus rapide, d'après mes testes, de :
~2% sous ff
~35% sous chrome
~65% sous ie

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
function compare(fn1,fn2){
	var MAX_DELAY = 20,
	NBR_TEST = 9;
	//
	var tab1=[],tab2=[],iter=1,delay=0,median=Math.round(NBR_TEST /2),time;
	while(delay<MAX_DELAY){
                time=new Date().getTime();
		for(var j=(iter*=2);j>0;j--){
			fn1();
			fn2();
		}
		delay = (new Date().getTime())-time;
	}
	for(;NBR_TEST>0;NBR_TEST--){
		// test fn1
		time = new Date().getTime();
		for(var j=iter;j>0;j--)
			fn1();
		tab1.push((new Date().getTime())-time);
		// test fn2
		time = new Date().getTime();
		for(var j=iter;j>0;j--)
			fn2();
		tab2.push((new Date().getTime())-time);
	}
	tab1.sort(function(a,b){return a-b;});
	tab2.sort(function(a,b){return a-b;});
	return (tab1[median]/tab2[median]);
}
//	test1
	function f1(u){
		for(var i=0;i<1 && !u;i++);
	}
	function f2(u){
		for(var i=0;i<1 && u==undefined;i++);
	}
	alert("ration (!u)/(u==undefined) : "+Math.round(compare(f1,f2)*100)+"% (1/ration  = "+Math.round(compare(f2,f1)*100)+"%)");
 
//	test2		
	function f11(u){
		for(var i=0;i<10000 && !u;i++);
	}
	function f22(u){
		for(var i=0;i<10000 && u==undefined;i++);
	}
	alert("ration (!u)/(u==undefined) : "+Math.round(compare(f11,f22)*100)+"% (1/ration = "+Math.round(compare(f22,f11)*100)+"%)");

[Auteur]

Arrêter de croire que la réponse à un problème simple passe nécessairement par l'utilisation d'une bibliothèque....


Ce n'est pas une critique envers les diverses bibliothèques javascript qui existent actuellement, mais je vois de plus en plus dans la résolution de problèmes simples des réponses du genre "utilise la bibliothèque unetelle ou une autre" alors que souvent 10 lignes de code suffisent à résoudre le problème.


Edit :
tiens je me répète

[sekaijin]

Arrêter de croire que la réponse à un problème simple passe nécessairement par l'utilisation d'une bibliothèque....


Ce n'est pas une critique envers les diverses bibliothèques javascript qui existent actuellement, mais je vois de plus en plus dans la résolution de problèmes simples des réponses du genre "utilise la bibliothèque unetelle ou une autre" alors que souvent 10 lignes de code suffisent à résoudre le problème.


Edit :
tiens je me répète

C'est sur qu'il vaut mieux 10 ligne de code.
Et à l'opposé arrêter de penser que vous ferrez mieux que des dizaines de developpeurs
et évitez de réécrire ce que d'autres ont fait dans des librairies de façon efficace et éprouvé.

donc en toutes circonstances soyez pragmatique.

A+JYT

[laurentg2003]

Perso , je pense qu'en informatique il faut réinventer la roue pour apprendre et comprendre
Si il ne faut pas faire ce que d'autres ont su faire en mieux
alors la peinture s'arrête au 15 ieme siècle et la science au debut du 20 ieme siecle (pourquoi s'interresser à la physique quantique...)
Ensuite une fois qu'on sait faire et qu'on doit develloper une grosse appli dans un team alors oui on utilise un framework comme le nom l'indique
et aprés tout ce qu'ont fait les autres en mieux c'est pas mon problème
quand je fais une appli je l'a fait certes mais mon but est de progresser
ensuite chacun a sa personnalité...

EDIT trés bon test de Willpower merci

[laurentg2003]

A madevilts
pourquoi eviter les getElementById();??

[Auteur]

C'est sur qu'il vaut mieux 10 ligne de code.
Et à l'opposé arrêter de penser que vous ferrez mieux que des dizaines de developpeurs
et évitez de réécrire ce que d'autres ont fait dans des librairies de façon efficace et éprouvé.

comme l'a indiqué laurentg2003, pour bien comprendre un langage, il faut parfois réinventer la roue. Même si le résultat n'est pas parfait passer par cette étape surtout si on est débutant est un bon exercice.

Après bien sûr pour des réaliser des choses élaborées, il est utile de passer par des bibliothèques.

[sekaijin]

Pourquoi à chaque fois on ne se concentre que sur une partie du post des gens
en omettant ce qui change tout son sens ?

donc en toutes circonstances soyez pragmatique.

C'est étonnant de voir que lorsque quelqu'un dit
il a A
ou il a B

Les réaction sont

il a A

et ceci mais cela

Heu les gars un post c'est un tout
Lisez le entier. et si vous en critiquez une partie n'oubliez de citer ce qui dans le reste dit exactement la même chose que votre critique.

A+JYT

[Willpower]

Ca commence à devenir aussi tendu que mon "string" ici.


Evidemment qu'il y a 2 façons de faire et que les 2 seront utiles dans certains cas, le gars qui n'utilise quasi pas JS pour faire son site, ne va pas se taper une lib de 100ko alors qu'il pourrait réécrire ce qu'il a besoin en 10 lignes.

Après s'il a d'avantage de code, ces 10 lignes peuvent être remplacées par une seule en utilisant un lib bien adaptée à ses besoins et qui pourrait être utile pour le reste de son code.

Et comme le disent les autres, parfois re-coder les 10 lignes soi-même est un bon moyen autodidacte pour apprendre.

Voila, nous sommes donc tous d'accord.

[sekaijin]

A madevilts
pourquoi eviter les getElementById();??

parce que ça consomme du temps et ça ne sert à rien la plus part du temps

exemple on cherche l''élément à chaque click

Code html :

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

1
2
3
4
5
<script>myFonction(id) {
   el = document.getElementById(id);
   //fait quelque chose avec el
}</script> 
<a id="45" onclick="return myFonction(45)">click</a>

le même

Code html :

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

1
2
3
4
<script>myFonction(el) {
   //fait quelque chose avec el
}</script> 
<a onclick="return myFonction(this)">click</a>

sur un objet autre que lui-même

Code html :

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

1
2
3
4
5
6
7
8
<div id="45">....
<script>
//on ne recherche q'une fois
els[45] = document.getElementById(45);
myFonction(id) {
   //fait quelque chose avec el[45]
}</script> 
<a onclick="return myFonction(45)">click</a>

là où je ne suis pas entièrement d'accord avec madevilts
c'est qu'en utilisant le dom tu te passe de toutes les recherches

Code :

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

1
2
3
4
5
6
7
div45 = document.createElement('DIV');
...
a = document.createElement('A');
a.ref=div45;
a.onclick = function () {
  //fait quelque chose avec this.ref
}

c'est surtout jouable lorsque tu par d'un HML vide et que tu construit ton appli entièrement en js. là tu a intérêt à garder les référence au objet que tu manipuleras de façon évènementielle pour ne pas avoir à les chercher tout le temps.


lorsque tu fait un site en HTML et que tu ne fais que y ajouter un peu de js
getElementById est parfait. mais pourquoi l'appeler à chaque événement si tu peux le faire une seule fois.

je pense à un script que j'ai vu récemment qui sur un timer toute les seconde va chercher un div et lui remplacer son contenu par l'heure courante.
alors que placer la référence au div dans une variable une première fois puis sur le timer utiliser la référence est bien plus efficace.

A+JYT

[Willpower]

+1 sekaijin


sinon j'ai lu ici que vous proscriviez d'utiliser la propriété length dans les boucle for.

le faisant souvent, j'ai voulu tester car au fond, ce n'est pas une méthode qui doit faire un calcule, c'est juste une propriété/attribut avec une valeur directe donc ça ne devrait pas être beaucoup plus lent niveau performance selon moi.

d'après mes tests :
len plutôt que a.len met :
-100% du temps sous google chrome
-57% sous internet explorer
-[37%~40%] sous firefox


en conclusion :
- je code mal
et/ou
- chrome est le seul parmi ces 3 moteurs à être bien conçu




nb: sinon effectivement utiliser tableau.length est également dangereux dans le cas où la boucle modifie le tableau en rajoutant ou retirant des éléments. (mais ce cas est rare et comporte d'autre dangers auxquels il faut être aussi très vigilant).

[marcha]

je pense à un script que j'ai vu récemment qui sur un timer toute les seconde va chercher un div et lui remplacer son contenu par l'heure courante.
alors que placer la référence au div dans une variable une première fois puis sur le timer utiliser la référence est bien plus efficace.

Qu'entends-tu par bien plus efficace ? gagner 10 nano secondes toutes les
secondes ? getElementById est optimisé aujourd'hui par les navigateur, c'est
un non sens de chercher à économiser quelques cycles CPU au détriment de
la simplicité d'écriture du code.

[Willpower]

Qu'entends-tu par bien plus efficace ? gagner 10 nano secondes toutes les
secondes ? getElementById est optimisé aujourd'hui par les navigateur, c'est
un non sens de chercher à économiser quelques cycles CPU au détriment de
la simplicité d'écriture du code.

ça dépendra surtout ce que tu en fais, si ton traitement est long la différence/le gain de temps sera infime et inversement :

Code :

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

1
2
3
4
5
6
7
8
9
	function f11(u){
		var compteur = document.getElementById("compteur");
		for(var i=0;i<1000;i++)
			compteur.innerHTML = i;
	}
	function f22(u){
		for(var i=0;i<1000;i++)
			document.getElementById("compteur").innerHTML = i;
	}

l'exécution de f11 met [90%~95%] du temps de f22 ... donc le gain est vraiment infime, car innerHTML est LENT.

Code :

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

1
2
3
4
5
6
7
8
9
	function f11(u){
		var compteur  = document.getElementById("compteur");
		for(var i=0;i<1000;i++)
			compteur.name = "o"+i;
	}
	function f22(u){
		for(var i=0;i<1000;i++)
			document.getElementById("compteur").name = "o"+i;
	}

l'exécution de f11 met [10%~37%] du temps de f22 ... donc le gain est déjà plus important, car l'accès à name est moins lent.

outre le gain de temps, je trouve que ça "éclairci" le code, donc plus lisible.

[Bovino]

Alors si je peux me permettre de recentrer un peu le débat, je rappelle que le titre de la discussion est

Bonnes pratiques JavaScript

Or les bonnes pratiques et les performances ne sont pas toujours en rapport, loin de là.
A titre d'exemple, les bonnes pratiques demandent habituellement de placer les scripts dans la balise <head> du document, ceci afin de pouvoir respecter le principe de séparation des couches ((X)HTML pour le contenu, CSS pour la présentation et JavaScript pour le comportement), or la recherche de performances préconise plus de placer les scripts juste avant la fermeture du </body>.

Du coup, pour répondre à

je pense à un script que j'ai vu récemment qui sur un timer toute les seconde va chercher un div et lui remplacer son contenu par l'heure courante.
alors que placer la référence au div dans une variable une première fois puis sur le timer utiliser la référence est bien plus efficace.

je partage l'opinion de sekaijin : à mon sens, la bonne pratique est de stocker dans une variable les données utilisées plusieurs fois plutôt que de les rechercher plusieurs fois.
C'est la même raison qui fait qu'il est préférable de stocker le length avant une boucle plutôt que de rechercher cette valeur à chaque itération.