Discussion :

[Lynix]

Les pires règles sont celles que je subis en ce moment:

Pour des programmes C
-Pas de else if
-Pas de goto (Je rappelle que ça peut être utile pour la gestion d'erreur en C)
-Un seul return par fonction
-Pas de break pour sortir des boucles (Donc oui il faut une variable testée à chaque itération pour décider de si on arrête la boucle).
-Pas de int, que des short

Le tout en même temps

Je deviens fou.

[el_slapper]

Pour des programmes C
-Pas de else if

est-ce qu'on peut faire un switch sur les booléens en C? Si on ne peut pas(en C# ou java, on ne peut pas, en cobol ou VBA on peut), alors c'est effectivement catastrophique. Sinon, c'est juste une question de style.

-Pas de goto (Je rappelle que ça peut être utile pour la gestion d'erreur en C)

l'eternel débat : mis dans de mauvaises mains, le goto a des conséquences nucléaires. Il est parfois utile, mais avec toujours un risque élevé. une interdiction compréhensible, bien que parfois lourdingue.

En Cobol, j'ai vu une variante de cette règle : le seul goto autorisé était le "GO TO FIN-PARAGRAPHE", justement pour la gestion d'erreur(les grands esprits se rencontrent).

-Un seul return par fonction

Pas de scandale à mon sens là-dessus. Lors des maintenances, ça permet d'éviter certains raccourcis non prévus.

-Pas de break pour sortir des boucles (Donc oui il faut une variable testée à chaque itération pour décider de si on arrête la boucle).

Même chose que pour le goto - sauf que le danger(et donc l'interêt de la règle) est beaucoup plus discutable. A noter qu'en cobol je n'ai pas de break, donc je me farcis souvent un booléen de sortie de boucle. Je préfère largement l'exit for du VBA. Emmerdant, pas catastrophique.

-Pas de int, que des short

Urk??? Ils ont bu quoi??? Avant, je trouvais les règles juste contraignantes(sauf peut-être la première), mais ça, c'est clairement du délire. Il arrive quand même fréquemment que fonctionellement on aie à gérer des entiers à 6 chiffres ou plus. Je mange des fichiers à 5 millions d'enregs au petit déjeuner - et 30 millions au diner. Comment je remplis le compteur de ma log si je suis limité à 65535?????

Sur ce dernier point, clairement, . ajouté à l'interdiction des break, on a sans doute à faire à quelqu'un d'un peu trop théorique, qui cherche à gagner de la mémoire à tout prix, et à ne jamais interrompre le flux du programme.

[Bluedeep]

est-ce qu'on peut faire un switch sur les booléens en C? Si on ne peut pas(en C# ou java, on ne peut pas, en cobol ou VBA on peut), alors c'est effectivement catastrophique. Sinon, c'est juste une question de style.

Il n'y a pas vraiment de booléen en C (au sens de type ne pouvant prendre que deux valeurs) mais tout ou presque peut être testé comme booléen.(non null ou non 0 => c'est vrai).

Et un switch sur variable bool fonctionne en C# , comme sur tout type ordinal.(en Java je n'en sais rien)

[Médinoc]

Par contre, en C# on peut faire des switch sur des strings, alors qu'en C on a généralement besoin de else if(strcmp(param, "--toto")==0)... (Ou bien on fait un switich sur une valeur de hachage)

[el_slapper]

(.../...)
Et un switch sur variable bool fonctionne en C# , comme sur tout type ordinal.(en Java je n'en sais rien)

hum, ça fait un an que je n'ai pas mis les mains sur visual studio, mais je suis à peu près sur que

Code :

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

1
2
3
4
5
Switch True {
    Case (a = b) {blabla; Break}
    Case (a = c) 'blabla; Break}
    Case (Else) {blabla; Break}
}

ça ne marche pas, là ou en VBA on peut faire

Code :

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

1
2
3
4
5
Select case true
    Case a=b:blabla
    Case a=c:blabla
    Case else:blabla
End select

(et désolé pour le C# pourri, ca n'est pas ce que je maitrise le mieux. ça doit se voir...).

Mais bon, tout ça pour dire que suivant le langage, une règle peut être utile, inutile, gênante, ou catastrophique. Pas de break cumulé à pas de Else If(j'avais pas fait le rapprochement), c'est tout à fait digne de ce fil, car il devient impossible de gérer des conditions fonctionnelles un peu recherchées.

[Bluedeep]

hum, ça fait un an que je n'ai pas mis les mains sur visual studio, mais je suis à peu près sur que

Code :

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

1
2
3
4
5
Switch True {
    Case (a = b) {blabla; Break}
    Case (a = c) 'blabla; Break}
    Case (Else) {blabla; Break}
}

ça ne marche pas,

Oui, mais ça c'est pas l'usage d'un switch; cela ressemble plus au Case SQL dans la variante sans valeur de référence :

Code :

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

1
2
3
4
5
6
case 
when (condition1) then (action1) 
......
when (condition_n) then (action_n) 
else (action_defaut) 
end [alias_name]

En l'espèce, un switch c'est :

Code :

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

1
2
3
4
5
6
7
8
9
10
switch(variable)
{
case constante1 :
action1();
break;
case constante2 :
action2();
break;
}

Et avec variable de type bool et case sur true et false ça marche très bien. Les "case" ne pouvant se faire que sur des constantes (et je crois que c'est le cas aussi en C, mais ça remonte trop loin; sauf qu'en C on ne peut travailler que sur des ordinaux, car le compilateur transforme cela en une "jump table" en général (souvenirs très lointains d'assembleur x86 ).

Bref, ne pas utiliser le "else if" est de toute manière sous-optimal dans la pluspart des cas.

[pmithrandir]

-Un seul return par fonction
-Pas de break pour sortir des boucles (Donc oui il faut une variable testée à chaque itération pour décider de si on arrête la boucle).

Pour moi, c'est deux bonnes pratiques.

Le return unique permet d'identifier a coup sur l'unique point de sortie.(ca aide a débugger plus vite)

Le break ne sert a rien, sauf si on ne sais pas faire la différence entre l'utilisation d'un while, d'un do while et d'un for.
Ce n'est pas parce que l'on itère une variable que l'on doit passer par un for.

Pour utiliser un for, il y a plusieurs conditions :
- Ne jamais changer la variable itérée à l'intérieur de la boucle.
- ne jamais interrompre la boucle
- toujours aller du début à la fin de l'itération.

Code :

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

for (init i=0;i<50;i++)

aura toujours 50 itérations, pas une de moins, pas une de plus.

[pseudocode]

Pour moi, c'est deux bonnes pratiques.

Le return unique permet d'identifier a coup sur l'unique point de sortie.(ca aide a débugger plus vite)

hum... C'est clair que ca va plus vite pour trouver où mettre le point d'arrêt dans l'IDE.

Mais, de mon point de vue, si on est obligé de mettre un point d'arrêt sur ce "return", c'est que:
1. on s'est planté sur les conditions de sorties.
2. le code est trop complexe pour trouver l'erreur sans le debuggeur.
3. qu'on aurait peut-être mieux fait de faire des conditions moins complexes et mettre plusieurs return.

Pour moi, le return unique c'est une règle qui a des avantages mais pas forcément une bonne pratique. Le return multiple a aussi ses avantages...

Code C :

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
fonction f(x,y,z) {
  // check pre-conditions
  if (condition on x,y,z)
    return ERROR_INVALID_PARAMETERS;
 
  for(...) {
    t=(x+y)/z;
    u=(2*t-x*y)+(x/t);
 
    // check invariants
    if (t<u)
      return ERROR_COMPUTATION_FAILURE;
  }
  result = 2*t+u;
 
  // check post-confitions
  if (condition on result) 
    return ERROR_INVALID_RESULT;
 
  return result;
}

[Médinoc]

Le "un seul return par fonction", je le trouve nuisible s'il s'applique aussi aux vérifications des paramètres: Ça encourage un "code boomerang" de if dans des if dans des if...

Une fois la validation terminée par contre, je temps à y adhérer dès qu'une fonction alloue la moindre ressource (une fonction de recherche qui n'alloue aucune ressource tend à retourner dès que ce qu'on cherche est trouvé, par contre).

[Bluedeep]

Pour moi, le return unique c'est une règle qui a des avantages mais pas forcément une bonne pratique. Le return multiple a aussi ses avantages...

Je suis d'accord mais je trouve que ton exemple n'est pas pertinent. Avec les langages actuels (Java, C#, ...) la pratique pour les conditions d'erreurs est plutôt de lever une exception. (bon, c'est vrai aussi que l'exemple est en js ....).

[el_slapper]

@bluedeep : ton switch, si(et seulement si) ma variable est booléenne, il ne sert pas à grand chose : autant faire un bête if. Et, si on a besoin de plus d'un test, d'un else if.

Je ne connaissais pas le CASE SQL, mais c'est exactement de celà dont je voulais parler. C'est un outil puissant, qui permet de remplacer les else if. Si on a ni l'un ni l'autre, ni le break ni le goto pour faire autrement, ça tourne à la torture.

Et soudain, grâce à ce débat(et toutes vos remarques fort pertinentes), je comprends mieux la complainte de ce pauvre Lynix : une seule règle à la con, ça se contourne. Quand tous les contournements sont interdits, il devient difficille de programmer.

[BenoitM]

Je suis d'accord mais je trouve que ton exemple n'est pas pertinent. Avec les langages actuels (Java, C#, ...) la pratique pour les conditions d'erreurs est plutôt de lever une exception. (bon, c'est vrai aussi que l'exemple est en js ....).

Me semble qu'on m'a toujours dit le contraire.
Les Exceptions sont lourd à traité

puis bon quelle est la différence entre un return -1; et un throw new Exception? :p

for (init i=0;i<50;i++)
aura toujours 50 itérations, pas une de moins, pas une de plus.

Perso quand je fais une recherche j'utilise un for avec un break;
Et dans des codes complexes je trouve qu'il est parfois plus facile d'identifier des return et de break que des if en casquade

Code :

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

1
2
3
4
5
6
7
for(int i=0;i<lst.Count;i++)
{
    if (lst[i] == elementRechercher)  return lst[i]
}
Element = CreerElement
return element

ou

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
int i=0;
while(!trouver && i<lst)
{
    if (lst[i] == elementRechercher) 
    {
        element = lst[i]
        trouver = true
    }
     i++;
}
if(!trouver)
{
 Element = CreerElement
}
return element;

Si on met uniquement un breakpoint sur le return on ne saura pas si l'element a été crée ou trouvé dans la liste.

[pmithrandir]

Me semble qu'on m'a toujours dit le contraire.
Les Exceptions sont lourd à traité

puis bon quelle est la différence entre un return -1; et un throw new Exception? :p

Les exceptions ont plusieurs avantages :
- elles sont rapides, en particulier lorsque l'exception est rare. Si c'est un comportement courant, on doit utiliser un if.(bref, on utilise pas les exceptions pour remplacer le if).
- Elles ont un nom, un contenu, un détail... bref, elles sont bien plus parlante et détaillées qu'un "-1"
- Elles font partie des règles générales. On a créé les exceptions pour gérer les erreurs, utiliser un autre système va rendre la tache plus difficile pour les autres développeurs.
- elle peuvent passer très facilement d'un niveau à l'autre de programmation... elle ont cette capacité a traverser les couches bien pratique selon le besoin.
- elles permettent de concentrer le code sur le besoin fonctionnel d'un coté, et les erreurs de l'autre(on les voit facilement)

Pour toutes ces raisons, au moins, je pense qu'il est largement préférable de se servir des exceptions si on les as à notre disposition.

[Grom61736]

Convention : Tout doit être passé dans l'URL.
On ne veut pas de variables de session ni de données qui transitent par POST.

Tout, tout dans l'URL même les mots de passe...

[bedomon]

Convention : Tout doit être passé dans l'URL.
On ne veut pas de variables de session ni de données qui transitent par POST.

Tout, tout dans l'URL même les mots de passe...

HA moi j'ai eu exactement l'inverse et tout devait passer en post et on devais toujours rester sur www.toto.com, donc adieu les favoris pour l'utilisateur

Sinon une petite remarque sur les returns multiples, je pense que ceux qui sont pour n'ont pas eu à faire de test unitaire dessus...

[Snack3r]

Bonsoir

Quand à moi, ça me dérangeais qu'une if en Java n'accepte qu'une valeur boolean surtout si on a l'habitude en C de mettre des entiers au lieu d'une expression dans if ^_^

[Médinoc]

Bonsoir

Quand à moi, ça me dérangeais qu'une if en Java n'accepte qu'une valeur boolean surtout si on a l'habitude en C de mettre des entiers au lieu d'une expression dans if ^_^

En fait, j'étais comme ça pendant mes premières années de codage C et C++, mais j'ai fini par me rendre compte qu'écrire du code explicite et lisible était plus important qu'écrire du code "compact" et "malin". Depuis, je fais explicitement toutes mes comparaisons (à commencer par celles à NULL), sauf pour les variables vraiment Booléennes (y compris les typedef int BOOL; et autres joyeusetés pré-C99).

Edit: Cela va de pair avec le fait de garder à l'esprit que strcmp() ne retourne pas un Booléen.

[pfeuh]

Salut,

écrire du code explicite et lisible était plus important qu'écrire du code "compact" et "malin".

Et c'est même plus important de mon point de vue que d'écrire du code respectant des règles. Les règles sont faites pour être de temps en temps brisées. Si nous respections toutes les règles, nous ne serions que des machines.

A+

Pfeuh

[Invité]

Je préfère un code un peu moche au départ mais qui permet une application qui fonctionne que du code propre d'une application qui ne marche pas. Ensuite au fil du temps, le refactoring permet d'améliorer encore et encore le code. Mais quand on fait du prototypage ou autre pratique similaire, la beauté du code n'importe pas vraiment, le but est de prouver au plus vite que ça fonctionne et ensuite d'améliorer, ajouter des briques petit à petit (à mon sens)

[Bebel]

Il faut faire gaffe, j'ai déjà vu du prototype (enfin maquette mais c'est pareil) se retrouver en production.

Bah quand la personne a développé la maquette sans code optimisé ou mise en forme (en pensant ne faire qu'une maquette) , quand tu dois le reprendre derrière tu souffres.