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.