Discussion :

[Lcf.vs]

Bonjour à tous,

Vous avez l'habitude de déclarer des fonctions... mais les connaissez-vous si bien que cela?

Certains les déclarent ainsi :

Code :

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

1
2
3
4
 
function fct() {
	// ce que vous voulez...
}

D'autres, plus soucieux de ne polluer l'espace global feront plutôt ainsi :

Code :

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

1
2
3
4
 
var fct = function () {
	// ce que vous voulez...
};

Mieux encore, afin de n'avoir qu'un seul bloc de déclaration par scope :

Code :

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

1
2
3
4
5
 
var fct;
fct = function () {
	// ce que vous voulez...
};

Mais cela n'est pas encore suffisant !

En effet, imaginons que votre fonction soit un constructeur :

Code :

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

1
2
3
4
5
6
 
var UnnamedConstructor;
UnnamedConstructor = function () {
	// ce que vous voulez...
};
console.log(new UnnamedConstructor()); // Object { }

Alors, oui, on a un objet mais, en console, il est impossible de savoir de quel constructeur provient cet objet, comme si on avait fait :

Code :

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

1
2
3
4
5
6
 
var NamedConstructor;
function NamedConstructor() {
	// ce que vous voulez...
}
console.log(new NamedConstructor()); // NamedConstructor { }

La solution, pour avoir le même rendu, sans polluer l'espace global?

Code :

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

1
2
3
4
5
6
 
var NamedConstructor;
NamedConstructor = function NamedConstructor() {
	// ce que vous voulez...
};
console.log(new NamedConstructor()); // NamedConstructor { }

Retenez bien, c'est le mot qui suit le mot-clé function qui nomme la fonction, pas la variable qui contient cette fonction.


Bien que l'usage de Function soit peu recommandé, de par son appel à eval(), il est parfois nécessaire de créer une fonction dynamique.

Alors, voici comment nommer une fonction dynamique :

Code :

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

1
2
3
4
5
6
7
8
 
var fct= (new Function(
	'var fct;'+
	'fct = function fct() {'+
	'	// ce que vous voulez...'+
	'};'+
	'return fct;'
))();

[cahnory]

Tiens, je ne connaissais pas du tout cette façon de déclarer une fonction (la dernière relative au constructeur).
Dommage qu'il faille passer par eval pour en bénéficier sur des "fonctions dynamiques", ça m'aurai bien servi sur mon script (un peu plus bas dans ce topic).

Sinon point de vue validité, c'est quelque chose de tout à fait… valide ? venant de toi je part sur l'aprioris que oui (car tu es un petit peu un intégriste d'ECMAScript, il faut bien le dire ) mais on ne sait jamais ^^.

[Lcf.vs]

Moi, intégriste?

Oui, tout à fait valide... Voici le détail : https://developer.mozilla.org/en-US/...ion_expression

[RomainVALERI]

intégriste peut-être mais il manque une parenthèse fermante dans ton dernier exemple ;D

[Lcf.vs]

Voilà, c'est corrigé... merci...

[Bovino]

J'avoue que j'ai du mal à comprendre l'intérêt de certaines choses...

Qu'y a-t-il de mal à déclarer ses fonctions normalement ?

Code :

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

1
2
3
function foo(){
    alert('bar');
}

Quel rapport entre polluer l'espace global et assigner une fonction à une variable ?

Code :

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

1
2
3
4
5
6
7
(function(){
    function foo(){
        alert('bar');
    }
    foo();
})()
foo()

foo() ne pollue en rien l'espace global est est déclarée de façon classique...

Quel est l'intérêt de séparer la déclaration d'une variable et son affectation ?

[Kaamo]

Quel est l'intérêt de séparer la déclaration d'une variable et son affectation ?

A part quand on ne peut qu'affecter la variable plus loin, c'est clair que je ne vois pas non plus la raison valable ... Pourquoi ne pas faire directement ?

Code javascript :

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

1
2
3
var NamedConstructor = function NamedConstructor() {
  // ce que vous voulez...
};

[Lcf.vs]

Bovino :

Ton premier code de Bovino pollue l'espace global (donc à ne pas faire), contrairement à ton 2ème, cependant, ce dernier présente tout de même un inconvénient, il faut créer un scope supplémentaire, avec les inconvénients qui vont avec.

En revanche, ne pas déclarer ses variables en début de scope peut avoir des conséquences fâcheuses :

Code :

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

1
2
3
4
5
6
7
var foo=3;
(function(){
    foo=function foo(){
        alert('bar');
    }
})();
console.log(foo)

Une façon plus propre serait donc de faire sa déclaration comme l'a fait Kaamo, pas de scope supplémentaire, uniformisation du code/des déclarations.

La seule différence avec ma solution finale, par rapport au code de Kaamo, c'est la distinction de deux blocs par scope :

1. La déclaration
2. L'affectation

Pourquoi ces deux blocs distincts? C'est simple, il faut voir celui de déclaration comme un sommaire des éléments du scope courant.

En faisant de la sorte, vous verrez que vous serez bien moins tentés de mettre plusieurs "var" dans un scope.

Cela permet de plus facilement repérer des variables non-déclarées et des variables déclarées mais inutilisées.

Autre détail, c'est que lorsque vous repliez les blocs internes d'un scope, vous pourrez aisément retrouver la liste de vos variables, sans pour autant voir le contenu des boucles, objets et autres joyeusetés multi-lignes.

Alors, si on le fait pour les variables, pourquoi ne pas le faire pour nos fonctions? l'idée, c'est, encore une fois, du code propre et uniforme.


PS : désolé pour le délai de réponse, j'étais à tout autre chose...

[fredoche]

salut

en lisant le post-it sur les bonnes pratiques du javascript, tu donnes en lien ce post dont tu es l'auteur, et donc me voilà ici et je te lis :

Bonjour à tous,

Vous avez l'habitude de déclarer des fonctions... mais les connaissez-vous si bien que cela?

Certains les déclarent ainsi :

Code :

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

1
2
3
4
 
function fct() {
	// ce que vous voulez...
}

D'autres, plus soucieux de ne polluer l'espace global feront plutôt ainsi :

Code :

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

1
2
3
4
 
var fct = function () {
	// ce que vous voulez...
};

[...]

La solution, pour avoir le même rendu, sans polluer l'espace global?

Code :

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

1
2
3
4
5
6
 
var NamedConstructor;
NamedConstructor = function NamedConstructor() {
	// ce que vous voulez...
};
console.log(new NamedConstructor()); // NamedConstructor { }

[...]

Et perso, je suis comme Bovino, j'ai du mal à te suivre, d'autant que ton premier exemple ne pollue pas l'espace global si il est dans un scope autre que le global.

Connais tu le fonctionnement de la déclaration de fonction (function statement) pour écrire cela ? par différence avec l'expression de fonction (function expression)

une déclaration de fonction fonctionne comme ceci :

Code :

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

function foo() {};

ce qui distingue une déclaration de fonction d'une expression de fonction c'est que la première instruction d'une ligne est le mot-clé function.
Ton premier exemple est une déclaration (statement)

Sous cette forme déclarative, function est un raccourci d'une expression function. Ainsi le précédent code (la déclaration - le statement par opposition à l'expression de function) est transformé en :

Code :

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

var foo = function foo() {};

il y a un mécanisme de hoisting associé à var qui fait que la déclaration va être transformée en :

Code :

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

1
2
3
var foo=undefined;
foo = function foo(){};
//ces 2 instructions sont remontées en haut du scope

Le hoisting dans ce cas précis (statement - déclaration) ne remonte pas seulement le var xxx= undefined mais aussi la définition de la function.
J'entends par remonter, remonter au début du scope.

Précision sur le hoisting : une déclaration de fonction ne peut pas prendre place dans des structures conditionnelles par exemple. Le hoisting fera qu'elle sera de toute façon déclarée et affectée.




Ce que tu proposes, c'est exactement ce que fait un function statement (une déclaration de fonction), mais en plus avec la garantie du mécanisme de hoisting, garantie que tu n'auras pas en le faisant à la main. Essaie si tu veux pour reprendre ton exemple :

Code :

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

1
2
function fred_constructor() {}
console.log(new fred_constructor())

ou alors j'ai pas compris où tu voulais en venir

Alors sans prétention hein ( Ca fait peut-être 2 semaines que je connais ces notions) .... mais j'ai envie de te retourner la question

Bonjour à tous,

Vous avez l'habitude de déclarer des fonctions... mais les connaissez-vous si bien que cela?

[Kaamo]

Arrêtez moi si je me trompe, mais voici ce que j'ai compris sur les différences entre les "expressions de fonctions" (functions expressions) et les déclarations de fonctions (functions declarations).

Selon la spéc. officielle.

En gros :
- Le code source du script est parsé
- Le code source du script est évalué
- Le contexte global d'exécution est initialisé
- Les déclarations de fonctions (function foo() { /* body code */ }) sont directement ajoutées à leur scope, avant d'exécuter le scope (le hoisting donc)
- Exécution du code ligne à ligne. Donc, les expressions de fonctions (var foo = function [foo]() { /* body code */ }), au même titre que les autres variables, sont ajoutées au scope à mesure de leur position dans le code.

Code :

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

1
2
alert(foo()); // Erreur, car à ce moment précis du code, foo n'est pas encore appliqué au scope d'exécution
var foo = function foo() { return 'coucou'; }

Code :

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

1
2
alert(foo()); // Ok, car à ce moment précis du code, foo a déjà été appliqué au scope d'exécution grâce au "hoisting"
function foo() { return 'coucou'; }

Une bonne pratique, si j'utilise les déclarations de fonctions, est de les déclarer en haut de chaque scope. Pour les expressions de fonctions, les déclarer avec var en début du scope, et leur donner une valeur ensuite. J'évite les fonctions anonymes, c'est mieux pour débugger.
J'englobe le tout dans un "module" (module pattern) et renvoie un objet avec tout ce qui doit être publique (entendre utile) :

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
var monProgramme = (function () {
  // déclaration de toutes les variables utilisées
  var maVar, maFonction; 
 
  // Remplir les variables
  maVar = "je suis privée et ne pollue pas";
  maFonction = function maFonction() {
    console.log("On ne peut pas m'appeler avec maFonction() de l'extérieur du module. Seulement avec log()");
  }
 
 // Retourne un objet ouvert au public qui contient ce qui doit l'être
 return {
   // setter qui permet de changer la valeur de maVar
   setMaVar: function setMaVar(valeur){
     maVar = valeur;
   },
 
   // getter qui permet de récupérer la valeur de maVar
   getMaVar: function getMaVar(){
     return maVar;
   },
 
   // Fonction Publique qui appelle une privée
   log: function log() {
     maFonction();
   }
 };
 
})();
 
console.log(monProgramme.getMaVar()); // "je suis privée et ne pollue pas"
console.log(monProgramme.maVar); // undefined car n'est pas présente dans l'objet rendu public
monProgramme.maVar = 'toto'; // modification de l'objet rendu public qui n'a rien à voir avec l'autre maVar
console.log(monProgramme.getMaVar()); // toujours "je suis privée et ne pollue pas"
monProgramme.setMaVar("on me change de l'extérieur car c'est permis !");
console.log(monProgramme.getMaVar()); // "on me change de l'extérieur car c'est permis !"

[fredoche]

salut

je crois en fin de compte que la bonne pratique c'est d'éviter les déclarations de fonction, les function statements (function foo() { /* body code */ }) que l'on distingue par la présence du mot clé function comme premier mot de la ligne d'instruction.

Cette forme est ambigüe, elle suppose de connaitre les règles de hoisting qui s'y appliquent, qui sont un petit poil plus complexe que pour une variable lambda.

Et puis j'ai dis une connerie dans mon précédent post : en fait une déclaration de fonction dans une structure conditionnelle n'en est pas une, dans ce type de structure, cela devient semble t'il forcément une expression de fonction.

Entre comprendre le hoisting, être sur que celui qui relira connait ce mécanisme et le cas particulier appliqué au function statement, le fait qu'un function statement devient function expression dans des structures conditionnelles, le fait que ce n'est pas invocable immédiatement.

Bref autant s'éviter des nœuds au cerveau et aller dans le sens de ton exemple kaamo

[SylvainPV]

Tu te trompes de problème Lcf.vs, ce n'est pas la façon dont on déclare la fonction qui est le souci ici, c'est juste l'absence de gestion correcte du scope. Utiliser une évalutation dynamique de code tel que tu le proposes, c'est très moche et très peu performant. Voilà comment j'ai l'habitude de gérer le scope de mes applications :

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
 
(function(){
 
var variablePrivee = 42;
 
function fonctionPrivee(){
     console.log("ceci ne pollue pas le scope global");
}
 
app.maFonctionPublique = function(){
      fonctionPrivee();
      return variablePrivee;
};
 
})(window.app = {}); //app sera la seule globale et le seul point d'entrée de mon application

A partir du moment où les gens ont compris le fonctionnement du scope, de la portée et des closures, on peut utiliser toutes les formes déclaratives sans peur de mettre le bazar dans le scope global.

Pour le problème du hoisting décrit par Kaamo, il est vrai qu'on évite le problème en déclarant toutes ses variables en début de fonction. Mais personnellement je trouve ça très pénible et fastidieux, et je ne fais quasiment jamais l'erreur d'utiliser une fonction ou une variable avant de l'avoir déclarée. Si on fait l'effort intellectuel de tout déclarer au début, alors on est tout aussi capables de déclarer à l'endroit adéquat, vous ne pensez pas ?

[Kaamo]

Si on fait l'effort intellectuel de tout déclarer au début, alors on est tout aussi capables de déclarer à l'endroit adéquat, vous ne pensez pas ?

Clairement ! Mais sur les projets multi-users, il faut en avoir conscience et être ferme sur les normes et le coding style à adopter. Enfin, si le "project lead" est bon, ça ne pose jamais de problème

[fredoche]

Ca a un intérêt de préciser le scope global comme tu le fais avec window ?

[SylvainPV]

A part montrer explicitement qu'on touche au scope global, non. J'ai pris pour habitude de ne jamais déclarer une variable sans le mot var ou sans préciser l'objet parent.

[Lcf.vs]

Désolé, les gars, je ne m'étais pas aperçu de la suite de cette discussion...

Je ne m'en suis rendu compte que, par hasard, en recommandant à quelqu'un de lire ma recommandation.

Comme dit précédemment, j'aime me servir de mon "bloc" de déclaration comme d'un sommaire de ce qui est utilisé au sein d'un scope.

De combiner ces 2 pratiques, avec l'affectation d'une fonction à une variable, cela permet d'éviter de mauvaises surprises et des incompréhensions à la relecture, en cas de bug.

Vous n'avez qu'à tester par vous-même, si nécessaire.

Code :

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

1
2
3
4
5
6
7
 
var f;
 
f = 1;
function f() {};
 
f(); // f is not a function

Sinon, lorsque je fais une fonction auto-exécutée, il y a 2 cas...

Pour celui où on attend une valeur de retour :

Code :

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

1
2
3
4
5
6
7
8
 
var a;
 
a = (function () {
    // ...
 
    return {};
}());

Et celui où on attend pas de valeur de retour :

Code :

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

1
2
3
4
 
void function () {
    // ...
}();

[SylvainPV]

Une fois qu'on connaît les règles de hoisting, on ne tombe plus jamais dans ce piège. Quitte à avoir de bonnes pratiques, je conseillerais plutôt de ne pas manipuler de variables de même nom et de type différent dans une même portée

[Lcf.vs]

On est bien d'accord sur ce point.

L'idée consistait simplement à ce qu'en regardant le "bloc" de déclaration, on ait tout de suite une idée de ce qui est déjà utilisé, indiquant, du coup, qu'il existe une référence de ce nom, au sein de ce scope.