Salut tous.
En lisant certains messages j'ai remarqué avec un certain étonnement que
plusieurs personnes ont l'air de ne pas trop aimer l'instruction break.
-je pense qu'ils doivent penser la meme chose pour continue-
Je dit que ca m'etonne car jusqu'ici j'avais plutot l'habitude de m'en
servir relativement souvent (pour sortir des boucles je parle. pas
uniquement dans les switch).
En fait étant donné que ce n'est pas souvent que je remet en question ma
facon de programmer, et que c'est peut etre un manque (?), je me dit
voila l'occasion de reflechir un peu, mais pas tout seul. alors voila je
vous demande:
Qu'est-ce que vous, très personnellement, vous pensez de break ?
et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle
devrait etre la maniere générale de s'en servir)
j'ajoute quand meme quelques details:
apparament sa s'approche un peu de l'utilisation des boucles et demies,
la aussi comme j'ai lu des critiques qui divergaient un peu j'ai essayé
de regarder le problème d'encore plus loin:
dans un langage (ici le C++) on met a notre disposition un jeu
d'instructions. c'est bien. heureusement avec il y a une notice
d'utilisation. c'est ce qui va nous permettre de réaliser des
algorithmes, pour modéliser des réactions logiques en fonction de causes
(variables).
Et vu de la on se dit alors, puisqu'on a cet outil a disposition, en
fait, n'importe comment que l'on dispose nos instructions, si
l'algorithme est réalisé on a atteind le but recherché.
si on a que ca, alors tout est permi.
si on ajoute une restriction d'optimisation et de temps de frappe
(économie du nombre de lignes) alors on arrive a un modele de
programmation qui dépendrait de la maniere de penser de chaque personne.
reste alors le critere de lisibilité, c'est lui qui est mis en question
dans ce thread finallement non ?
c'est pour ce dernier et unique critere que break est des fois accepté
et des fois non ? pas vrai ? vous pensez que j'ai raison ?
est-ce que ce critere là est-il finalement pas un bridage de l'esprit
des programmeurs ?
bon j'espere que vous allez pas me prendre pour un troll, moi je me pose
certaines question, si je cherche a répondre tout seul je risque de pas
prendre les bonnes directions, alors voila je fait appel a vous, merci.
| Salut tous. | En lisant certains messages j'ai remarqué avec un certain étonnement | que plusieurs personnes ont l'air de ne pas trop aimer l'instruction | break.
c'est pour quoi faire ?
| -je pense qu'ils doivent penser la meme chose pour continue- | Je dit que ca m'etonne car jusqu'ici j'avais plutot l'habitude de m'en | servir relativement souvent (pour sortir des boucles je parle. pas | uniquement dans les switch).
ma compréhension des boucles est que c'est un machin qui répète une collection d'instructions tant qu'une certaine condition est vérifiée. Quand je lis un programme qui utilisent des boucles (je n'en connais pas beaucoup d'utiles qui n'en font pas), j'ai besoin de savoir au moins deux choses clairement bien delimitées : (1) marquer clairement les frontières de la boucle (2) la condition d'arrêt
c'est un peu comme avec les fonctions : (a) le nom doit être assez suggestif de ce qu'elle fait (b) sa documentation ainsi que le type des arguments. Je n'ai pas envie de voir son implémentation pour savoir ce qu'elle fait. De la même manière, je n'ai pas envie de lire le corps de la bouocle pour savoir quand est ce qu'elle s'arrête. Souvent, je me contente d'un simple
for_each(begin, end, do_something);
(ou variantes) lorsque cela est applicable.
| Qu'est-ce que vous, très personnellement, vous pensez de break ? | et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle | devrait etre la maniere générale de s'en servir)
Break en lui même n'est Le Mal. C'est l'utilisation qu'on en fait. Visibelement, on n'a pas souvent le choix avec switch. Pour une boucle « for », son utilisation n'est requise que si elle simplifie réellement la compréhension et l'écriture du code.
-- Gaby
"Lightness1024!" <nomail@nomansland.com> writes:
| Salut tous.
| En lisant certains messages j'ai remarqué avec un certain étonnement
| que plusieurs personnes ont l'air de ne pas trop aimer l'instruction
| break.
c'est pour quoi faire ?
| -je pense qu'ils doivent penser la meme chose pour continue-
| Je dit que ca m'etonne car jusqu'ici j'avais plutot l'habitude de m'en
| servir relativement souvent (pour sortir des boucles je parle. pas
| uniquement dans les switch).
ma compréhension des boucles est que c'est un machin qui répète une
collection d'instructions tant qu'une certaine condition est vérifiée.
Quand je lis un programme qui utilisent des boucles (je n'en connais
pas beaucoup d'utiles qui n'en font pas), j'ai besoin de savoir au
moins deux choses clairement bien delimitées :
(1) marquer clairement les frontières de la boucle
(2) la condition d'arrêt
c'est un peu comme avec les fonctions : (a) le nom doit être assez
suggestif de ce qu'elle fait (b) sa documentation ainsi que le type
des arguments. Je n'ai pas envie de voir son implémentation pour
savoir ce qu'elle fait. De la même manière, je n'ai pas envie de lire
le corps de la bouocle pour savoir quand est ce qu'elle s'arrête.
Souvent, je me contente d'un simple
for_each(begin, end, do_something);
(ou variantes) lorsque cela est applicable.
| Qu'est-ce que vous, très personnellement, vous pensez de break ?
| et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle
| devrait etre la maniere générale de s'en servir)
Break en lui même n'est Le Mal. C'est l'utilisation qu'on en fait.
Visibelement, on n'a pas souvent le choix avec switch. Pour une boucle
« for », son utilisation n'est requise que si elle simplifie
réellement la compréhension et l'écriture du code.
| Salut tous. | En lisant certains messages j'ai remarqué avec un certain étonnement | que plusieurs personnes ont l'air de ne pas trop aimer l'instruction | break.
c'est pour quoi faire ?
| -je pense qu'ils doivent penser la meme chose pour continue- | Je dit que ca m'etonne car jusqu'ici j'avais plutot l'habitude de m'en | servir relativement souvent (pour sortir des boucles je parle. pas | uniquement dans les switch).
ma compréhension des boucles est que c'est un machin qui répète une collection d'instructions tant qu'une certaine condition est vérifiée. Quand je lis un programme qui utilisent des boucles (je n'en connais pas beaucoup d'utiles qui n'en font pas), j'ai besoin de savoir au moins deux choses clairement bien delimitées : (1) marquer clairement les frontières de la boucle (2) la condition d'arrêt
c'est un peu comme avec les fonctions : (a) le nom doit être assez suggestif de ce qu'elle fait (b) sa documentation ainsi que le type des arguments. Je n'ai pas envie de voir son implémentation pour savoir ce qu'elle fait. De la même manière, je n'ai pas envie de lire le corps de la bouocle pour savoir quand est ce qu'elle s'arrête. Souvent, je me contente d'un simple
for_each(begin, end, do_something);
(ou variantes) lorsque cela est applicable.
| Qu'est-ce que vous, très personnellement, vous pensez de break ? | et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle | devrait etre la maniere générale de s'en servir)
Break en lui même n'est Le Mal. C'est l'utilisation qu'on en fait. Visibelement, on n'a pas souvent le choix avec switch. Pour une boucle « for », son utilisation n'est requise que si elle simplifie réellement la compréhension et l'écriture du code.
-- Gaby
amerio
En lisant certains messages j'ai remarqué avec un certain étonnement que plusieurs personnes ont l'air de ne pas trop aimer l'instruction break. -je pense qu'ils doivent penser la meme chose pour continue-
Ah ben ca m'interresse le point de vue sur "continue". A titre perso, je sais que je prefere ecrire : for (...) { test1=...; if (!test1) continue; test2 = ...; if (!test2) continue;
.... // le vrai travail }
plutot que :
for (...) { test1=..; if (test1) { test2=...; if (test2) { ... // le vrai travail } } }
que je trouve plus lourd, surtout quand il y a plusieurs if enchainé comme ca. (on retrouve parfois 4-5 niveau d'accolades, si si, j'en ai vu).
En lisant certains messages j'ai remarqué avec un certain étonnement que
plusieurs personnes ont l'air de ne pas trop aimer l'instruction break.
-je pense qu'ils doivent penser la meme chose pour continue-
Ah ben ca m'interresse le point de vue sur "continue".
A titre perso, je sais que je prefere ecrire :
for (...)
{
test1=...;
if (!test1)
continue;
test2 = ...;
if (!test2)
continue;
.... // le vrai travail
}
plutot que :
for (...)
{
test1=..;
if (test1)
{
test2=...;
if (test2)
{
... // le vrai travail
}
}
}
que je trouve plus lourd, surtout quand il y a plusieurs if enchainé comme ca.
(on retrouve parfois 4-5 niveau d'accolades, si si, j'en ai vu).
En lisant certains messages j'ai remarqué avec un certain étonnement que plusieurs personnes ont l'air de ne pas trop aimer l'instruction break. -je pense qu'ils doivent penser la meme chose pour continue-
Ah ben ca m'interresse le point de vue sur "continue". A titre perso, je sais que je prefere ecrire : for (...) { test1=...; if (!test1) continue; test2 = ...; if (!test2) continue;
.... // le vrai travail }
plutot que :
for (...) { test1=..; if (test1) { test2=...; if (test2) { ... // le vrai travail } } }
que je trouve plus lourd, surtout quand il y a plusieurs if enchainé comme ca. (on retrouve parfois 4-5 niveau d'accolades, si si, j'en ai vu).
Christophe Lephay
Lightness1024! wrote:
Qu'est-ce que vous, très personnellement, vous pensez de break ? et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle devrait etre la maniere générale de s'en servir)
Je pense que le break n'est pas un problème en lui-même : il le devient quand il est partie intégrante d'un style qui consiste à écrire du code tout en sachant véritablement ce qu'il fait *après* l'avoir exécuté.
Si on considère qu'une fonction devrait être courte (pour des question de lisibilité autant que conceptuelles), alors il n'y a pas de raison de faire de même avec break. C'est parfois avantageux de mettre le code dans une fonction quand on arrive à la quinzième imbrication ;) Voir le post de Gaby, où il fait référence à for_each, par exemple...
Maintenant, si tu as besoin de break (pour une "boucle et demi", par exemple), alors il n'est pas nécessaire de compliquer le code sous prétexte qu'on veut éviter un break...
Chris
Lightness1024! wrote:
Qu'est-ce que vous, très personnellement, vous pensez de break ?
et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle
devrait etre la maniere générale de s'en servir)
Je pense que le break n'est pas un problème en lui-même : il le devient
quand il est partie intégrante d'un style qui consiste à écrire du code tout
en sachant véritablement ce qu'il fait *après* l'avoir exécuté.
Si on considère qu'une fonction devrait être courte (pour des question de
lisibilité autant que conceptuelles), alors il n'y a pas de raison de faire
de même avec break. C'est parfois avantageux de mettre le code dans une
fonction quand on arrive à la quinzième imbrication ;) Voir le post de Gaby,
où il fait référence à for_each, par exemple...
Maintenant, si tu as besoin de break (pour une "boucle et demi", par
exemple), alors il n'est pas nécessaire de compliquer le code sous prétexte
qu'on veut éviter un break...
Qu'est-ce que vous, très personnellement, vous pensez de break ? et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle devrait etre la maniere générale de s'en servir)
Je pense que le break n'est pas un problème en lui-même : il le devient quand il est partie intégrante d'un style qui consiste à écrire du code tout en sachant véritablement ce qu'il fait *après* l'avoir exécuté.
Si on considère qu'une fonction devrait être courte (pour des question de lisibilité autant que conceptuelles), alors il n'y a pas de raison de faire de même avec break. C'est parfois avantageux de mettre le code dans une fonction quand on arrive à la quinzième imbrication ;) Voir le post de Gaby, où il fait référence à for_each, par exemple...
Maintenant, si tu as besoin de break (pour une "boucle et demi", par exemple), alors il n'est pas nécessaire de compliquer le code sous prétexte qu'on veut éviter un break...
Chris
Jean-Marc Molina
Excellentes questions :)
J'ai une profonde aversion pour les breaks, désolé. Pour moi un algorithme doit être logique, presque liquide. On doit pouvoir le lire de haut en bas et en comprendre son fonctionnement sans perdre le fil. Le break c'est un peu comme un lien hypertexte, si on clique dessus pendant une lecture, on perd le fil. Utiliser les breaks c'est un peu perdre le contrôle car on ajoute implicitement des effets de bord. Par exemple on peut faire un break sur une simple condition, mais peut-être qu'il fallait d'abord passer le système dans un état stable, validation de certaines variables, états, etc... Pour image on peut encore comparer ça à une exception. Tu peux parfaitement remplacer un break par une exception, tu mets un throw et un catch derrière ta boucle pour "continue" ton algorithme. Ça reste très brutal et pour moi ça n'a rien de logique, il ne s'agit pas d'une exception mais d'un simplement changement d'état. Je ne suis jamais tombé dans un cas où j'ai eu besoin d'un break ou encore pire d'un continue, enfin depuis que je fais de la POO. Mais même en C je ne l'ai jamais vraiment utilisé. J'ai vu des atrocités comme utiliser des breaks et continues dans des fonctions pseudo-récursives, et on oublie même de parler des "return". Si le problème se pose il vaut mieux développer son algorithme, voir quels sont ses défauts pour le simplifier, peut-être le linéariser ; certains utilisent le break/continue pour optimiser leur algorithme, avant d'optimiser il faut peut-être en concevoir un qui tient la route :). Pour éviter les if imbriqués il suffit d'utiliser des fonctions, tout simplement. Les mauvaises langues parlent alors de fonctions imbriquées mais ça dépend du traitement. Il m'arrive fréquemment d'avoir 3-4 if imbriqués pour valider un composant d'une application graphique par exemple. Je valide une donnée, une autre, puis une autre, chacune ayant son message d'erreur si nécessaire. Ça peut ressembler à un if OK, if OK, if OK, sinon ERREUR. Quel bel algorithme hihi :).
Je pense que c'est une bonne image, l'alogithme peut être comparé à un hypertexte. Un point d'entrée, plusieurs points de sortie. Dans mon cas je préfère largement avoir un point d'entrée et un minimum de points de sortie, garder le contrôle. Je commence au do, je termine au while avec un état qui me permet de déterminer la cause de la sortie de ma boucle. Pas un do, break, peut-être un continue avec un futur hypothétique break, encore un break puis pourquoi pas un while (si il sert encore à quelque chose).
Mort aux breaks, vive l'algorithmique :) JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
Excellentes questions :)
J'ai une profonde aversion pour les breaks, désolé.
Pour moi un algorithme doit être logique, presque liquide. On doit pouvoir
le lire de haut en bas et en comprendre son fonctionnement sans perdre le
fil. Le break c'est un peu comme un lien hypertexte, si on clique dessus
pendant une lecture, on perd le fil.
Utiliser les breaks c'est un peu perdre le contrôle car on ajoute
implicitement des effets de bord. Par exemple on peut faire un break sur une
simple condition, mais peut-être qu'il fallait d'abord passer le système
dans un état stable, validation de certaines variables, états, etc... Pour
image on peut encore comparer ça à une exception. Tu peux parfaitement
remplacer un break par une exception, tu mets un throw et un catch derrière
ta boucle pour "continue" ton algorithme. Ça reste très brutal et pour moi
ça n'a rien de logique, il ne s'agit pas d'une exception mais d'un
simplement changement d'état. Je ne suis jamais tombé dans un cas où j'ai eu
besoin d'un break ou encore pire d'un continue, enfin depuis que je fais de
la POO. Mais même en C je ne l'ai jamais vraiment utilisé. J'ai vu des
atrocités comme utiliser des breaks et continues dans des fonctions
pseudo-récursives, et on oublie même de parler des "return".
Si le problème se pose il vaut mieux développer son algorithme, voir quels
sont ses défauts pour le simplifier, peut-être le linéariser ; certains
utilisent le break/continue pour optimiser leur algorithme, avant
d'optimiser il faut peut-être en concevoir un qui tient la route :). Pour
éviter les if imbriqués il suffit d'utiliser des fonctions, tout simplement.
Les mauvaises langues parlent alors de fonctions imbriquées mais ça dépend
du traitement. Il m'arrive fréquemment d'avoir 3-4 if imbriqués pour valider
un composant d'une application graphique par exemple. Je valide une donnée,
une autre, puis une autre, chacune ayant son message d'erreur si nécessaire.
Ça peut ressembler à un if OK, if OK, if OK, sinon ERREUR. Quel bel
algorithme hihi :).
Je pense que c'est une bonne image, l'alogithme peut être comparé à un
hypertexte. Un point d'entrée, plusieurs points de sortie. Dans mon cas je
préfère largement avoir un point d'entrée et un minimum de points de sortie,
garder le contrôle. Je commence au do, je termine au while avec un état qui
me permet de déterminer la cause de la sortie de ma boucle. Pas un do,
break, peut-être un continue avec un futur hypothétique break, encore un
break puis pourquoi pas un while (si il sert encore à quelque chose).
Mort aux breaks, vive l'algorithmique :)
JM
--
Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
J'ai une profonde aversion pour les breaks, désolé. Pour moi un algorithme doit être logique, presque liquide. On doit pouvoir le lire de haut en bas et en comprendre son fonctionnement sans perdre le fil. Le break c'est un peu comme un lien hypertexte, si on clique dessus pendant une lecture, on perd le fil. Utiliser les breaks c'est un peu perdre le contrôle car on ajoute implicitement des effets de bord. Par exemple on peut faire un break sur une simple condition, mais peut-être qu'il fallait d'abord passer le système dans un état stable, validation de certaines variables, états, etc... Pour image on peut encore comparer ça à une exception. Tu peux parfaitement remplacer un break par une exception, tu mets un throw et un catch derrière ta boucle pour "continue" ton algorithme. Ça reste très brutal et pour moi ça n'a rien de logique, il ne s'agit pas d'une exception mais d'un simplement changement d'état. Je ne suis jamais tombé dans un cas où j'ai eu besoin d'un break ou encore pire d'un continue, enfin depuis que je fais de la POO. Mais même en C je ne l'ai jamais vraiment utilisé. J'ai vu des atrocités comme utiliser des breaks et continues dans des fonctions pseudo-récursives, et on oublie même de parler des "return". Si le problème se pose il vaut mieux développer son algorithme, voir quels sont ses défauts pour le simplifier, peut-être le linéariser ; certains utilisent le break/continue pour optimiser leur algorithme, avant d'optimiser il faut peut-être en concevoir un qui tient la route :). Pour éviter les if imbriqués il suffit d'utiliser des fonctions, tout simplement. Les mauvaises langues parlent alors de fonctions imbriquées mais ça dépend du traitement. Il m'arrive fréquemment d'avoir 3-4 if imbriqués pour valider un composant d'une application graphique par exemple. Je valide une donnée, une autre, puis une autre, chacune ayant son message d'erreur si nécessaire. Ça peut ressembler à un if OK, if OK, if OK, sinon ERREUR. Quel bel algorithme hihi :).
Je pense que c'est une bonne image, l'alogithme peut être comparé à un hypertexte. Un point d'entrée, plusieurs points de sortie. Dans mon cas je préfère largement avoir un point d'entrée et un minimum de points de sortie, garder le contrôle. Je commence au do, je termine au while avec un état qui me permet de déterminer la cause de la sortie de ma boucle. Pas un do, break, peut-être un continue avec un futur hypothétique break, encore un break puis pourquoi pas un while (si il sert encore à quelque chose).
Mort aux breaks, vive l'algorithmique :) JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
delta
"Jean-Marc Molina" a écrit dans le message de news:bol62t$qho$
Le break c'est un peu comme un lien hypertexte, si on clique dessus pendant une lecture, on perd le fil.
Ne penses tu pas qu une imbrication de if then else peut rendre un algorithme presque illisible ?
d'optimiser il faut peut-être en concevoir un qui tient la route :). Pour éviter les if imbriqués il suffit d'utiliser des fonctions, tout simplement.
L appel d une fonction a un cout, non ?
Mort aux breaks, vive l'algorithmique :)
Je suis pret a te soumettre une methode dirigee par une profonde imbrication de if then else, sous la contrainte que l efficacite est essentielle. J aimerai bien avoir ton avis parce que ce que j ai ecrit ne me convient pas.
"Jean-Marc Molina" <goa_pasdepourriel_@ifrance.com> a écrit dans le message
de news:bol62t$qho$1@news-reader3.wanadoo.fr...
Le break c'est un peu comme un lien hypertexte, si on clique dessus
pendant une lecture, on perd le fil.
Ne penses tu pas qu une imbrication de if then else peut rendre un
algorithme
presque illisible ?
d'optimiser il faut peut-être en concevoir un qui tient la route :). Pour
éviter les if imbriqués il suffit d'utiliser des fonctions, tout
simplement.
L appel d une fonction a un cout, non ?
Mort aux breaks, vive l'algorithmique :)
Je suis pret a te soumettre une methode dirigee par une profonde imbrication
de if then else, sous la contrainte que l efficacite est essentielle.
J aimerai bien avoir ton avis parce que ce que j ai ecrit ne me convient
pas.
"Jean-Marc Molina" a écrit dans le message de news:bol62t$qho$
Le break c'est un peu comme un lien hypertexte, si on clique dessus pendant une lecture, on perd le fil.
Ne penses tu pas qu une imbrication de if then else peut rendre un algorithme presque illisible ?
d'optimiser il faut peut-être en concevoir un qui tient la route :). Pour éviter les if imbriqués il suffit d'utiliser des fonctions, tout simplement.
L appel d une fonction a un cout, non ?
Mort aux breaks, vive l'algorithmique :)
Je suis pret a te soumettre une methode dirigee par une profonde imbrication de if then else, sous la contrainte que l efficacite est essentielle. J aimerai bien avoir ton avis parce que ce que j ai ecrit ne me convient pas.
Fabien LE LEZ
On Sun, 9 Nov 2003 11:49:01 +0100, "Jean-Marc Molina" wrote:
J'ai une profonde aversion pour les breaks, désolé. Pour moi un algorithme doit être logique, presque liquide. On doit pouvoir le lire de haut en bas et en comprendre son fonctionnement sans perdre le fil. Le break c'est un peu comme un lien hypertexte, si on clique dessus pendant une lecture, on perd le fil.
Ça me paraît bien théorique, tout ça. J'ai sur break un point de vue assez similaire à celui de Gaby : break est une solution pour résoudre certains problèmes ; il a des inconvénients, mais si les avantages sont supérieurs aux inconvénients, on peut tout à fait l'utiliser. Mais c'est vrai qu'en pratique, on en a assez rarement besoin.
-- ;-)
On Sun, 9 Nov 2003 11:49:01 +0100, "Jean-Marc Molina"
<goa_pasdepourriel_@ifrance.com> wrote:
J'ai une profonde aversion pour les breaks, désolé.
Pour moi un algorithme doit être logique, presque liquide. On doit pouvoir
le lire de haut en bas et en comprendre son fonctionnement sans perdre le
fil. Le break c'est un peu comme un lien hypertexte, si on clique dessus
pendant une lecture, on perd le fil.
Ça me paraît bien théorique, tout ça. J'ai sur break un point de vue
assez similaire à celui de Gaby : break est une solution pour résoudre
certains problèmes ; il a des inconvénients, mais si les avantages
sont supérieurs aux inconvénients, on peut tout à fait l'utiliser.
Mais c'est vrai qu'en pratique, on en a assez rarement besoin.
On Sun, 9 Nov 2003 11:49:01 +0100, "Jean-Marc Molina" wrote:
J'ai une profonde aversion pour les breaks, désolé. Pour moi un algorithme doit être logique, presque liquide. On doit pouvoir le lire de haut en bas et en comprendre son fonctionnement sans perdre le fil. Le break c'est un peu comme un lien hypertexte, si on clique dessus pendant une lecture, on perd le fil.
Ça me paraît bien théorique, tout ça. J'ai sur break un point de vue assez similaire à celui de Gaby : break est une solution pour résoudre certains problèmes ; il a des inconvénients, mais si les avantages sont supérieurs aux inconvénients, on peut tout à fait l'utiliser. Mais c'est vrai qu'en pratique, on en a assez rarement besoin.
-- ;-)
espie
Bof, bof, bof... dans pas mal de cas, pour moi, le break et le continue sont juste la facon `naturelle' de continuer. Par exemple, lorsque je suis en train de traiter un fichier de configuration `oriente ligne', zapper les lignes de commentaires avec un `continue' marche tres bien.
Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au milieu de la boucle qui donnent naturellement des
while (1) { debut_de_boucle(); if (cond) break; fin_de_boucle(); }
Lorsque je n'ai pas de STL sous la main, une bonne boucle de recherche dans un tableau ressemble souvent a:
for (i = 0; i < n; i++) { if (element_trouve) break; }
pour moi...
(et, dans des cas plus compliques, c'est souvent plus immediat de faire le boulot directement que d'aller pondre l'adaptateur qui va bien pour utiliser un algo standard... et si c'est du code qui ne sera pas etendu plus tard, ca ne sert a rien de vouloir faire general a outrance)
c'est infiniment plus clair de separer proprement le parcours du tableau de la recherche de l'element. Je trouve particulierement atroce la variante pascalienne
for (i = 0; i < n && !found; i++) { if (element_trouve) found = true; }
Le `found', dans ce contexte, n'ajoute pour moi que du bruit, et n'est clairement pas idiomatique, ni du C, ni du C++.
En terme de robustesse du code, il n'apporte rien non plus. Aucune des deux variantes n'est plus difficile a prouver que l'autre.
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
Bof, bof, bof... dans pas mal de cas, pour moi, le break et le continue
sont juste la facon `naturelle' de continuer. Par exemple, lorsque je
suis en train de traiter un fichier de configuration `oriente ligne',
zapper les lignes de commentaires avec un `continue' marche tres bien.
Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au
milieu de la boucle qui donnent naturellement des
while (1) {
debut_de_boucle();
if (cond)
break;
fin_de_boucle();
}
Lorsque je n'ai pas de STL sous la main, une
bonne boucle de recherche dans un tableau ressemble souvent a:
for (i = 0; i < n; i++) {
if (element_trouve)
break;
}
pour moi...
(et, dans des cas plus compliques, c'est souvent plus immediat de faire
le boulot directement que d'aller pondre l'adaptateur qui va bien pour
utiliser un algo standard... et si c'est du code qui ne sera pas etendu
plus tard, ca ne sert a rien de vouloir faire general a outrance)
c'est infiniment plus clair de separer proprement le parcours du tableau
de la recherche de l'element. Je trouve particulierement atroce la
variante pascalienne
for (i = 0; i < n && !found; i++) {
if (element_trouve)
found = true;
}
Le `found', dans ce contexte, n'ajoute pour moi que du bruit, et n'est
clairement pas idiomatique, ni du C, ni du C++.
En terme de robustesse du code, il n'apporte rien non plus.
Aucune des deux variantes n'est plus difficile a prouver que l'autre.
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans
le meme temps, on nie certaines des constructions idiomatiques les plus
repandues du-dit langage...
Bof, bof, bof... dans pas mal de cas, pour moi, le break et le continue sont juste la facon `naturelle' de continuer. Par exemple, lorsque je suis en train de traiter un fichier de configuration `oriente ligne', zapper les lignes de commentaires avec un `continue' marche tres bien.
Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au milieu de la boucle qui donnent naturellement des
while (1) { debut_de_boucle(); if (cond) break; fin_de_boucle(); }
Lorsque je n'ai pas de STL sous la main, une bonne boucle de recherche dans un tableau ressemble souvent a:
for (i = 0; i < n; i++) { if (element_trouve) break; }
pour moi...
(et, dans des cas plus compliques, c'est souvent plus immediat de faire le boulot directement que d'aller pondre l'adaptateur qui va bien pour utiliser un algo standard... et si c'est du code qui ne sera pas etendu plus tard, ca ne sert a rien de vouloir faire general a outrance)
c'est infiniment plus clair de separer proprement le parcours du tableau de la recherche de l'element. Je trouve particulierement atroce la variante pascalienne
for (i = 0; i < n && !found; i++) { if (element_trouve) found = true; }
Le `found', dans ce contexte, n'ajoute pour moi que du bruit, et n'est clairement pas idiomatique, ni du C, ni du C++.
En terme de robustesse du code, il n'apporte rien non plus. Aucune des deux variantes n'est plus difficile a prouver que l'autre.
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
Lightness1024!
Marc Espie wrote:
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
oui ! c'est pour ca que j'ai été étonné de voir que certaines personnes sont horipilées par un break.
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans
le meme temps, on nie certaines des constructions idiomatiques les plus
repandues du-dit langage...
oui ! c'est pour ca que j'ai été étonné de voir que certaines personnes
sont horipilées par un break.
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
oui ! c'est pour ca que j'ai été étonné de voir que certaines personnes sont horipilées par un break.
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
En effet. Mais il faut tout de même faire attention. On ne va pas non plus se mettre à utiliser goto à tour de bras parce qu'il fait partie du langage... -- <=- Michaël "Cortex" Monerau -=> "I move for no man" - Monthy Python
Marc Espie wrote:
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si,
dans le meme temps, on nie certaines des constructions idiomatiques
les plus repandues du-dit langage...
En effet. Mais il faut tout de même faire attention. On ne va pas non plus
se mettre à utiliser goto à tour de bras parce qu'il fait partie du
langage...
--
<=- Michaël "Cortex" Monerau -=>
"I move for no man" - Monthy Python
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
En effet. Mais il faut tout de même faire attention. On ne va pas non plus se mettre à utiliser goto à tour de bras parce qu'il fait partie du langage... -- <=- Michaël "Cortex" Monerau -=> "I move for no man" - Monthy Python
Fabien LE LEZ
On Sun, 9 Nov 2003 14:34:28 +0000 (UTC), (Marc Espie) wrote:
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
Mais break est-il une "expression idiomatique" ou une "sale bidouille à la 'goto'" ? That is the question...
-- ;-)
On Sun, 9 Nov 2003 14:34:28 +0000 (UTC), espie@tetto.gentiane.org
(Marc Espie) wrote:
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans
le meme temps, on nie certaines des constructions idiomatiques les plus
repandues du-dit langage...
Mais break est-il une "expression idiomatique" ou une "sale bidouille
à la 'goto'" ? That is the question...
On Sun, 9 Nov 2003 14:34:28 +0000 (UTC), (Marc Espie) wrote:
J'avoue que je ne vois pas trop l'interet d'utiliser un langage si, dans le meme temps, on nie certaines des constructions idiomatiques les plus repandues du-dit langage...
Mais break est-il une "expression idiomatique" ou une "sale bidouille à la 'goto'" ? That is the question...
