Discussion:Langage C++/Boucles & Structures Conditionnelles

Remarque 1

Les recommandations données quant à (l') (la non) utilisation de else if sont très vivement critiquables. Les arguments donnés portent sur un exemple volontairement très mal écrit et intuitivement très mauvais : FaitAInferieurB() n’est pas appelé si a = 5, quelque soit b, c’est illogique. En utilisant else if on aurait tout aussi bien pu écrire l'exemple ainsi :

 if (a > b)
 {
   FaitASuperieurB();
 }
 else if (a == b)
 {
   FaitAEgalB();
 }
 else if (a != 5)
 {
   FaitAInferieurB();
 }
 else
 {
   FaisAInferieurBEtAEgalCinq();
 }
 FaitAutreChose();

Et avec des fonctions plus intuitives :

 if (a > b)
 {
   FaitASuperieurB();
 }
 else if (a == b)
 {
   FaitAEgalB();
 }
 else
 {
   FaitAInferieurB();
 }
 if (a == 5)
 {
   FaisAEgalCinq();
 }
 FaitLaSuite();

Ce qui n’est pas moins lisible que l'exemple final, au contraire. Je conseille donc vivement de supprimer l'incitation à ne pas utiliser les else if qui font partie intégrante du langage. Leur utilisation ou non se fait principalement en fonction du contexte. Il faut utiliser la syntaxe la plus intuitive et donc celle qui correspond le mieux à la pensée pour un problème donné. En règle général je dirais que l’utilisation de else if doit se faire dans un schéma à n "cas" (ici on a bien 3 cas distincts : inférieur, égal, supérieur), mais où l’utilisation de "switch" s'avère impossible à cause de la nature des tests (ce qui est très fréquent). --84.102.39.159 9 novembre 2008 à 17:24 (UTC)

Je CONFIRME que l’utilisation de "else if" est une forme de bidouillage basée sur l’utilisation d'une facilité d'écriture du compilateur qui ne doit en aucun cas être utilisée en développement sous peine de bug de logique difficiles à déceler. La forme "if(){}else{if(){}else{}}"est beaucoup plus claire et ne change en rien le comportement du code. De plus cela permet de voir les portées de codes pour les éventuelles variables créés dans les imbrications de if.

Enfin le code de démonstration n'a pas à être remis en cause car comme il n’est pas concret il peut très bien exister (ne connaissant pas les valeurs de "a" et de "b") et en fait, il existe puisque je me suis inspiré d'un code réel ou "b" est justement supérieur à 5. Ppignol 22 février 2011 à 14:21 (UTC)

Remarque 2

Autre chose, l’utilisation d'accolades, qui est même vivement recommandée dans l’article au sein des case d'un switch ne sert strictement à rien... Elle n'améliore pas la lisibilité du programme, car dans ce cas elle est dépendante de l'indentation et n'a aucun effet sur son exécution. De plus, l'instruction break peut être présente avant la fin d'un case, au sein d'une structure conditionnelle par exemple. Pire, le break peut ne pas être présent et le case suivant sera donc exécuté (accolades ou pas) ! L'utilisation d'accolades peut donc même porter à confusion ! --84.102.39.159 9 novembre 2008 à 18:04 (UTC)

On peut le voir sous cet angle et faire du code pourris ou le voir sous l'angle du professionnel qui n'a pas de temps à perdre avec une écriture du code incompréhensible et qui pour des raisons de lisibilité préfèrera mettre son code entre accolades pour bien séparer ses portées de codes. Si vous voulez obfusquer votre code libre à vous. Ici c’est un cour ou je tente de donner un peu de rigueur à l'écriture de code. Si vous voulez utiliser toutes les subtilités du langage je ne vous en empêche pas mais ne venez pas pleurer si une personne qualifié en informatique viens vous dire que vous travaillez comme un sagouin et qu’il met 2 fois plus de temps à entrer dans votre code que s'il était écrit selon des conventions claires ! Ppignol 22 février 2011 à 14:45 (UTC)