Discussion :

[devback]

Bonjour à tous,

Je développe depuis quelques années maintenant mais je me posais une petite question.
Depuis toujours mes professeurs me disent qu'un 'break' n'est pas algorithmiquement correct.

En langage C, je m'efforce donc de faire:

unsigned char b = 0;
while(b==0 && ...)
if(...)b=1;

alors qu'il serait possible de faire:
for(...)if(...)break;

Pour l'ordinateur, la solution que j'utilise, c'est à l'évidence un test à faire en plus à chaque tour à l'inverse du break qui permettrait de sortir directement.

Alors... faut-il bannir le break ? Est-ce impropre ?

Merci beaucoup,
devback

[Obsidian]

Ma préférence va largement au break, et je pense que c'est le cas de beaucoup de monde.

Ce que l'on reproche généralement au break, c'est un peu le même procès que l'on tient à goto, mais ce n'est pas valable car cela ne brise pas le concept de programmation structurée : on sait toujours où on va sortir même si la boucle évolue, et on sait toujours pourquoi.

Ces récriminations peuvent être justifiées s'il y a des post-conditions à l'intérieur de la boucle qui imposent qu'un cycle se finisse proprement (comme par exemple l'ouverture et la re-fermeture d'un fichier) mais, dans ce cas, c'est au programmeur de faire le bon choix.

Personnellement, je trouve que remplacer un break statique et connu à la compilation par un booléen en mémoire dont la valeur dépend du contexte à l'exécution, c'est un remède bien pire que le mal.

[ram-0000]

Ha !!! le débat théoriciens contre praticiens.

Le débat sur le break (et aussi le continue qui doit être du même ordre d'idée) rejoint le débat du goto (à un moindre niveau tout de même).

Je suis développeur et à ce titre, je suis amené à écrire du code mais surtout , à le relire.

Ce qui m'importe le plus lors de cette relecture, c'est d'avoir une structure de code facile à lire et à comprendre.

Les tests tels que tu les décrits "while(b==0 && ...)" sont parfois illisibles et il vaut mieux alors un "break" (ou "continue") bien placé qui améliore la compréhension et la relecture du code.

Pour moi, lorsque j'écris, je ne m'interdit jamais un "break" ou un "continue" si cela doit simplifier le code au risque de choquer les théoriciens du langage. Il m'est même arrivé d'écrire des instructions "goto" (oui oui, j'assume) car dans certains cas (gestion des erreurs principalement), cela simplifiait vraiment beaucoup la structure de code.

[souviron34]

Il m'est même arrivé d'écrire des instructions "goto" (oui oui, j'assume) car dans certains cas (gestion des erreurs principalement), cela simplifiait vraiment beaucoup la structure de code.

Autant je suis totalement d'accord pour les break et continue, autant pour les erreurs et des goto pas du tout...

Un simple codage des erreurs incrémental (par exemple négatif), et un break ou un if suffit..

[Obsidian]

'faudrait surtout militer pour une réhabilitation propre et encadrée, dans les écoles, de l'usage du goto et autres artifices parce qu'ils ont beau être souvent révélateurs de mauvaises pratiques, ils sont loins d'être les abominations que l'on prétend.

Je crois que c'est le bon moment pour placer ceci :

[souviron34]

encore une fois, je proteste par rapport aux goto, mais sinon effectivement "l'abomination des breaks et continue" va assez bien avec les règles du style "une fonction de pas plus de 50 lignes", "une fonction ne contenant qu'un if", "une fonction par fichier", et autres...

Bref toutes choses dont l'application stricte , bien que vue de temps en temps dans les gros projets, n'en est pas moins une abomination de maintenance... et de programmation... (et quelques fois de conception)

Mais nous sommes tous des c.ns, n'est-ce pas... et des c.ns remplaçables par d'autres c.ns..

[diogene]

Il y a une grande différence entre les instructions entrainant la rupture du flux "normal" des instructions : d'une part break, continue et return et d'autre part goto. Pour les premières, on sait immédiatement où va se poursuivre l'exécution du programme sans avoir à explorer le reste du code. Il n'y a pas rupture pour le lecteur dans son examen du code et elles affectent donc beaucoup moins la lisibilité du code que ce que fait un goto.

[matafan]

Pour moi il n'y a pas de différence, un goto n'est pas plus difficile à suivre qu'un break. Chercher une accolade fermante ou chercher un label, ça ne change pas grand chose, surtout si le nom du label est bien choisi.

Je n'ai rien ni contre les break, ni contre les goto, à partir du moment où ils permettent de simplifier le code.

C'est de toute façon un faux débat. Ce qui est important c'est la lisibilité du code, et la lisibilité du code vient avant tout de la clareté de l'algorithme, du choix du nom des variables, du découpage en blocs, des commentaires, de l'indentation, et de la constance des règles de programmation. Un code avec des breaks (et dans une moindre mesure des goto) peut être bien plus clair qu'un code sans.

[uknow]

Il est à mon gout insensé de rajouter une variable ( surtout qu'il faut lui trouver un bon nom ) rien que pour éviter d'utiliser un break.

J'ai toujours utilisé le break pour les cas à part dans le fonctionnement normal d'une boucle (une espèce d'erreur fatale qui survient par exemple).

Quant au goto, assez rares sont les fois où son usage est judicieux.
D'ailleurs les comparaisons des usages du goto et du break m'ont toujours étonné.

Je rejoins quelques avis plus haut qui ne se privent pas de ces deux opérateurs quand cela rend le code plus clair.

[Obsidian]

Surtout que si on commence à supprimer break et continue parce qu'ils provoquent une rupture de séquence, il faudra supprimer return pour les mêmes raisons et laisser les fonctions courir jusqu'à leur terme.

En soi, ça pourrait se plaider aussi. Mais dans ce cas, il faudra se rabattre complètement sur les if imbriqués qui, eux, sont décriés par d'autres personnes.

[pfeuh]

Salut,

il faudra supprimer return pour les mêmes raisons et laisser les fonctions courir jusqu'à leur terme.

Tout à fait, force 8 sur l'Echelle de Goret d'Emmanuel Delahaye, 3ème puce...

A+

Pfeuh

[Obsidian]

Tout à fait, force 8 sur l'Echelle de Goret d'Emmanuel Delahaye, 3ème puce...

Mouais, 'faut se méfier de ce genre de sites aussi, car crier bien fort et tourner d'emblée des concepts en ridicule avant d'en débattre, c'est souvent un bon moyen d'arriver à ses fins en évitant la confrontation. Il y a beaucoup de vrai dans ce site, mais :

1. Je mets quiconque au défi d'écrire un programme qui évite 100 % des points cités sur cette page ;
2. Il y a quand même beaucoup de points très contestables : interdiction d'utiliser float (mais interdiction d'utiliser long int également quand ce n'est pas nécessaire), interdiction d'écrire des fonctions de plus de 50 à 100 lignes, interdiction de passer une structure en argument de fonction, etc.

Tous ces concepts ont été inventés et mis en place parce qu'ils ont une justification technique. Ils ne sont pas là pour servir de pommes de discorde, desquelles les programmeurs vertueux doivent s'efforcer de ne jamais s'approcher.

Ce genre de directives va conduire le codeur à subdiviser son programme en une myriade de fonctions qui ne seront pas plus faciles à lire. Et personnellement, je considère qu'une fonction qui n'est appelée qu'à un seul endroit dans un programme a de fortes chances d'être injustifiée.

[f-k-z]

Ce genre de directives va conduire le codeur à subdiviser son programme en une myriade de fonctions qui ne seront pas plus faciles à lire. Et personnellement, je considère qu'une fonction qui n'est appelée qu'à un seul endroit dans un programme a de fortes chances d'être injustifiée.

Yop,

Je me permet de reprendre ce paragraphe pour y apporter une petite variation personnelle. Une fonction peut ne très bien être appelée qu'une seule fois dans un programme, mais il faut que celle-ci suive un cheminement logique et SOIT réutilisable dans un autre contexte en restant logique.

C'est-à-dire qu'une fonction comme la suivante est pour moi inutile, et Obsidian sera d'accord avec moi :p

Code :

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

1
2
3
void AfficherEntier(int entier){
    printf("%d\n",entier);
}

Mais au contraire une fonction comme celle-ci sera plus appréciée, avec un commentaire avant ou dedans:

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
int bin2dec(char *bin)   
{
  int  b , k, n;
  int  len, sum = 0; 
 
  len = strlen(bin) - 1;
  for(k = 0; k <= len; k++) 
  {
    b = 1;
    n = (bin[k] - '0');
    b = b<<(len-k);
    sum = sum + n * b;
  }
  return(sum);
}

Car elle a une utilité simple: convertir une chaine binaire, en une valeur décimale. Et peut donc très bien être réutilisée dans un autre programme. (En respectant bien les tests sur la chaine envoyée (composée que de 1 et 0 , qu'elle fini bien par un '\0' etcetc...) )

++

Fiki

[koala01]

Salut,

A titre tout à fait personnel, je dois dire que je préfères bien souvent essayer de limiter l'utilisation de break aux tests à choix multiples (switch, case)...

Il y a une raison bien simple à cet état de fait : j'ai toujours un doute quant à savoir où le break va me renvoyer, alors que si je teste une variable, je sais exactement quelle partie du code sera exécutée si la condition est remplie et quelle autre ne le sera pas.

De plus, le fait de disposer de variable clairement identifiée dont on peut, le cas échéans, vérifier la valeur lors du debug présente, selon moi, l'intérêt certain de pouvoir "tracer" d'une manière ou d'une autre cette valeur.

Par contre, bien que j'essayerai dans la mesure du possible de mettre en oeuvre le SESE (Single Entry Single Exit), je n'éprouverai pas la moindre difficulté morale à placer un return en milieu de fonction si la logique est capable de repérer le fait que rien de ce qui suit ne sera exécuté / exécutable.

En d'autre mots, je pourrais dire que j'utilise:

• régulièrement return ailleurs qu'en fin de fonction
• rarement break ailleurs que dans un test à choix multiple (où l'on n'a de toutes façons pas vraiment le choix)
• encore plus rarement continue
• jamais gogo