Discussion :

[sekaijin]

...
J'en suis donc revenu et écris dorénavant

Code :

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

1
2
3
if( prop.action){
  prop.action();
}

10 ans après la lecture reste claire, simplement à la différence de Watilin je mets une double accolade

Je mets mois aussi les accolades.

il y a des années voici ce qui met arrivé :
dans un dev (56 000 lignes de code environ) un developpeur à écrit une méthode très bien documenté. et dans un passage il fait un test et en dessous mets un gros commentaire du pourquoi du comment il fait appel à une fonction.
les années passent et un autre développeur intervient en urgence pour dépanner la chose suite à un changement de contexte. il commente l'appel à la fonction est ajoute un commentaire en MAJUSCULE pour alerter sur le fait que la rustine doit être corrigé. les tests se passent bien et le truc par en production
quelque temps plus tard je suis appelé à la rescousse car un bug apparemment aléatoire se produit.

voici ce qu'il se passait

Code php :

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
if (macondition)
    /* ici le gros commentaire d'origine
    ...
 
 
 
 
 
 
 
 
 
 
 
 
 
    sur beaucoup de lignes
    */
    #appelDeLaFunction(); //Désactivé en urgence
    /* ici GROS COMMENTAIRE SUR LA DESACTIVATION DE LA LIGNE DU DESSUS
    ...
 
 
 
 
 
 
 
 
    lui aussi sur plusieurs lignes
    */
 
/*
commentaire sur le parcours de la boucle
*/
while(myvar in collection) {
}

ceux qui on un oeil averti auront peut être vu qu'en commentant appelDeLaFunction(); la boucle while était soumise à la condition if (macondition).
c'était à l'époque du franc mais l'unité de base dans ce truc était le GF giga franc je vous laisse imaginer la panique lorsque le truc à produit des erreurs de l'ordre de la dizaine de GF.

A+JYT

[Watilin]

J'y tiens à mon if en une ligne, et je pense qu'il est fool-proof Je vais tenter de vous expliquer pourquoi.

Code :

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

if (condition) instruction;

À la lecture, aucun doute possible, même si on est fatigué ou si on (re)découvre le code. L'instruction appartient au if, et les instructions suivantes non.

À l'écriture, si je veux rajouter une instruction dans le if, je suis obligé de passer à la ligne, vous me suivez ? Et au moment de passer à la ligne, je rajoute les accolades.

Code :

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

1
2
3
4
if (condition) {
  instruction;
  instruction;
}

Et je ne crois pas qu'il soit possible d'oublier les accolades à ce moment-là. Vous n'êtes pas d'accord ?

[fredoche]

Comme tu l'écris, pourvu que tu te tiennes à toujours l'écrire sur la même ligne, ça va.

Je rencontre parfois la forme où l'instruction est à la ligne suivante, juste décalé d'un tab (avec un peu de chance), et si c'est moi qui le lit, je rajouterai les accolades. Sinon mon cerveau a du mal.

JSLint t'obligerait à mettre les accolades, je viens de vérifier.

[Kaamo]

Code :

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

1
2
if (condition) instruction;
instructionDeux;

ça me choque maintenant, même en sautant une ligne après la condition.

Avant je m'octroyais ce droit mais quand je repasse sur mon code j'ajoute systématiquement des accolades.

[fredoche]

il y a aussi les if ... else if ... else qui utilise cette faculté d'accolades optionnelles si l'instruction est unique

Code :

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

1
2
3
4
5
6
7
8
 
if (truc) {
//...
} else if (bidule) {
 
} else {
 
}

elseif existe dans d'autres langages, tandis que là nous avons bien 2 ifs indépendants.
Ca revient certainement au même qu'un elseif mais il faut garder dans un petit coin de l'esprit comment/pourquoi ça fonctionne.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
if (truc) {
	//...
} 
else {
	if (bidule) {
		//...
	} 
	else {
		//...
	}
}

tu utiliserais quelle version kaamo ?

[Kaamo]

En effet, c'est bien d'en avoir conscience

Mais j'adopte le style de beaucoup de "grands comptes" (jQuery, Crockford, etc). Ce qui est quand même plus intuitif et lisible.

Code :

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

1
2
3
4
5
6
7
if (condition) {
  statements
} else if (condition) {
  statements
} else {
  statements
}

Qui est, comme tu l'as dit, le raccourci de ceci.

Code :

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

1
2
3
4
5
6
7
8
9
if (condition) {
  statements
} else {
  if (condition) {
    statements
  } else {
    statements
  }
}

Mais quand le else if intervient je me pose toujours la question de le remplacer par quelque chose d'autre ! Soit un switch qui est souvent plus adapté. Ou alors il y a peut-être une mauvaise conception dans l'air.

Exemple bateau, que je vois parfois dans certains codes :

Code :

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

1
2
3
4
5
6
7
if (animal.estUneGrenouille()) {
  animal.coasse();
} else if (animal.estUnChien()) {
  animal.aboie();
} else if (animal.estUnLion()) {
  animal.rugit();
}

Ici, on pourrait penser à un switch, mais le polymorphisme serait plus adapté. Tout se passe en amont au moment de la création des objets, il faut les assigner au bon prototype

Code :

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

animal.crier()

[SylvainPV]

Le grand débat du passage à la ligne avec if Je n'ai jamais su me décider, du coup je n'utilise plus que des conditions ternaires.

Code :

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

condition ? (function(){ instruction; })() : null;

Non sérieusement ça n'a pas autant d'importance que certains voudraient y prêter. Je connais quelques collègues qui seraient prêts à s'engueuler pour ça

[fredoche]

rooohhh

là je sens qu'il y a un truc

Mais quand le else if intervient je me pose toujours la question de le remplacer par quelque chose d'autre ! Soit un switch qui est souvent plus adapté. Ou alors il y a peut-être une mauvaise conception dans l'air.

Exemple bateau, que je vois parfois dans certains codes :

Code :

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

1
2
3
4
5
6
7
if (animal.estUneGrenouille()) {
  animal.coasse();
} else if (animal.estUnChien()) {
  animal.aboie();
} else if (animal.estUnLion()) {
  animal.rugit();
}

Ici, on pourrait penser à un switch, mais le polymorphisme serait plus adapté. Tout se passe en amont au moment de la création des objets, il faut les assigner au bon prototype

Code :

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

animal.crier()

Bon je vais aller me documenter sur ce concept qui m'échappe, mais si tu as envie de développer un petit peu, fais moi plaisir...

C'est bien toi qui nous sert du duckducktyping ça te travaille quand même

[fredoche]

En effet, c'est bien d'en avoir conscience

Mais j'adopte le style de beaucoup de "grands comptes" (jQuery, Crockford, etc). Ce qui est quand même plus intuitif et lisible.

Aparté, je l'ai adopté comme professeur Crockford

la série de vidéos ici est vraiment passionnante :
http://yuiblog.com/crockford/
C'est un personnage très intéressant
Et clairement il change ma vision de ce langage, ainsi que vous ici.

Je vais aller regarder ces liens

[Kaamo]

J'avais vu passer un truc il y a quelques temps comme quoi le if c'était le mal et qu'il fallait passer par autre chose, notamment du polymorphisme.
Mais c'est dans des cas bien précis quand même. Bien sûr que le if est indispensable, mais pas tout le temps.

Si on reprend l'exemple ci-dessus, l'animal doit crier différemment selon son type. On peut imaginer un système simple, comme ci-dessus, avec des if imbriqués.

Mais aussi, on peut imaginer cela autrement. Bon il faut avouer que l'exemple est bidon, mais c'est pour illustrer.

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
var Animal = {
  crie: function() {
    return "je n'ai pas de cri spécifique";
  }
};
 
var Grenouille = Object.create(Animal);
Grenouille.crie = function() {
  return "crôa crôa !";
}
 
var Lion = Object.create(Animal);
Lion.crie = function() {
  return "grôôôâr grôôôâr !";
}
 
var Chien = Object.create(Animal);
Chien.crie = function() {
  return "woof woof !";
}
 
var ET = Object.create(Animal);
 
var animal = Object.create(Chien); // ou Lion, ou Grenouille
animal.crie(); // woof woof !
 
var animal = Object.create(ET);
animal.crie(); // je n'ai pas de cri spécifique

[SylvainPV]

Et de la même façon, les for/while pourraient être remplacés par des fonctions/objets itérateurs. C'est vrai, toutes les petites instructions logiques qu'on a l'habitude d'utiliser pourraient être remplacées par un équivalent "orienté objet". On a jamais su sortir complètement de la programmation séquentielle, ça paraîtrait inimaginable de manipuler un langage sans if et sans for. Et comme tous les trucs inimaginables, ça m'intéresse beaucoup
Quelqu'un veulent tenter une petite expérience à base d'Object.prototype pour trouver un équivalent à tous les patterns séquentiels usuels ?

[Kaamo]

Héhé l'idée est à creuser ! ça sent le JavaScript ludique, saison 3, ça !
Il semblerait qu'il y ait déjà eu des mouvements anti-if et anti-for par le passé