Bonjour,
Faut-il préferer les boucles for aux boucles while ?
double puissance(double x, int n)
{
double resultat;
for (resultat = 1.0 ; n > 0 ; --n)
resultat *= x;
return resultat;
}
double puissanceBis(double x, int n)
{
double resultat = 1.0;
while ( n > 0)
{
resultat *= x;
--n;
}
return resultat;
}
void setup() {
Serial.begin(115200);
Serial.println(puissanceBis(15, 3));
Serial.println(puissance(15, 2));
}
void loop() {
// put your main code here, to run repeatedly:
}
Dans ce code, les deux boucles des fonctions puissance et puissanceBis conduisent strictement au même résultat. Pourtant :
dans la boucle for le code est facilement lisible et modifiable ;
avec la boucle while son initialisation est parfois très loin de la boucle elle-même (définition des variables) ; le code qui assure son évolution est souvent mélangé avec le corps de la boucle.
faut-il préférez une boucle for à une boucle while afin de minimiser les erreurs ?
PS : Il est en général facile de remplacer une boucle while par une boucle for A = initialisation, B = Condition, C = évolution, D = instructions
Je n'ai pas de réponse toute faites, je ferais une réponse de normand.
Il faudrait voir ce que le compilateur produit, pour savoir ce qui est plus optimiser à chaque cas.
Il n'y a aucune raison pour que les initialisations soient loin de la boucle.
Mais ma façon de faire est que j'utilise celui qui est le plus adapté en français à ce que je veux faire.
Ouai ca ne veut rien dire, ma phrase.
Que ferais tu par défaut toi?
double puissance(double x, int n)
{
double resultat = 1.0;
while (n-- > 0) resultat *= x; // ou juste n-- mais s’assurer avant que n est positif
return resultat;
}
En fait l'auteur de mon livre fait une erreur en transposant toutes les boucles for suivant le même schéma dans les boucles while et inversement . La preuve :
void lettres(int pin, int vitesse, int frequence, int index) {
const char *ptr = codeMorse[index].representation;
while (char symbole = pgm_read_byte(ptr++)) {
if (symbole == '.' ) point(pin, vitesse, frequence);
else tiret(pin, vitesse, frequence);
delay(vitesse); // entre chaque symbole constitutif d'une lettre un espacement de temps court
}
delay(2 * vitesse); // entre chaque lettre un espacement de temps un peu plus long (X3 en comptant le délai existant à la fin du code
}
Cette obsession de l'optimisation !
Souvent, ce qui est important, c'est d'avoir un code suffisamment clair pour que je puisse le reprendre 2 ans plus tard sans me prendre le chou pour savoir ce qu'il fait.
On optimise uniquement si cela est nécessaire.
Personnellement j'utilise le verbe optimiser à la fois pour la machine mais aussi pour le programmeur. C'est peut-être une erreur. Sinon @biggil a raison mais @J-M-L aussi :
Chacun doit faire ce qui lui correspond le mieux en fonction des limites matériels et de ses propres limites.
En fait, j'ai ouvert ce fil de discussion car l'auteur du livre est Maître de Conférences à l’INSA Hauts-de-France où il enseigne la programmation depuis de nombreuses années. Du coup, je lui en veux un peu d'avoir autant simplifié sachant que son ouvrage récent de 800 pages s'adresse à des lecteurs étudiants d'université ou en école d'ingénieur.
Je voulais donc avoir votre avis sur cette vision simpliste ou trop généraliste qui selon lui oppose les boucles while et for.
Merci @J-M-L pour votre réponse, elle est explicite et c'est elle que je retiens bien évidemment.
En gros j'utilise for lorsqu'il y a un comptage, avec des bornes (pour i allant de 0 à N...)
Et while ( condition ) lorsque condition est une expression logique (true or false)
Je recherche avant tout la lisibilité, dans un souci de maintenance ( c-à-d y replonger 2 ans plus tard)
Pas vraiment, la seul préoccupation de la lisibilité, conduit alors a un gaspillage des ressources que se soit matériel ou énergétique.
Comme la lisibilité est aussi une affaire d'habitude, il peut être aussi utile de savoir changer ses habitudes.
La programmation sur du matériel comme les Arduinos est souvent une affaire de compromis.
En fait l’optimisateur de code détecte la boucle et va générer sans doute le même code, celui qui est plus efficace, pour l’un ou l’autre. Donc oui la lisibilité du code doit être le premier facteur, mais il est relatif.
Je pense ça aussi, donc en général j'utilise des syntaxes 'optimisées' plus pour m'amuser que pour optimiser le code source, sachant que le compilateur va passer derrière et le réécrire à sa manière...
Bonjour,
Parce qu'il part du postulat que toutes les boucles for sont transposables en boucles while et inversement. Ce qui est faux. Cette règle existe effectivement mais il y a des boucles while qui ne sont pas transposables et qui ont leur utilité bien spécifique sans pour autant être illisibles ! @J-M-L en a fait la démonstration sur ce fil de discussion. J'en ai repérés un certain nombre sur le forum et ailleurs. J'en ai moi mêmes écrites quelques unes...
Voilà vu le niveau de l'auteur et celui annoncé dans le résumé du livre, je m'attendais à des explications moins simplistes.
Mais ce n'est pas correct. Ici votre boucle while est lisible et ne correspond pas à ce schéma trop simple de transposition de boucles. Votre boucle est bien plus subtile qu'avec une boucle for ... Il y a d'autres exemples qui donnent clairement un sens à l'utilisation des boucles while ou du moins qui démontrent qu'elles ne sont pas inutiles et plus difficile à comprendre.
C'est pour cette raison que je trouve cette opposition injustifiée dans certains cas.
Ce qui me choque n'est pas bien compliqué à comprendre !
L'auteur du livre déconseille l'usage des boucles while au profit des boucles for !!!
C'est simple non !
Certaines boucles while contrairement à ce qu'il explique sont lisibles, claires et ne sont pas susceptibles d'entraîner des erreurs ou des problèmes de maintenance. D'autres sont effectivements problématiques ...
Ceci dit, ce livre hormis cette aversion pour les boucles while est très bien fait et j'y apprends tous les jours quelque chose de nouveau.
Oui c’est tout à fait discutable, je ne suis pas d’accord avec lui, le while à son intérêt.
Il ne dit pas cependant qu’il n’y a pas possibilité de remplacer l’une par l’autre, il dit le contraire. C’est toujours possible, ce qui est vrai, même si l’écriture doit être un peu différente
