Informatique """SELECT * FROM forum WHERE subject LIKE '%informatique%' ORDER BY date;"""

[Seigneur Ombre]

Cas d'école : répéter la saisie d'un mot de passe jusqu'à ce qu'il soit correct

Et bien par rapport au cas d'école

Code : Tout sélectionner

mdpUserInput = ''
nbrAttempts = 0

while mdpUserInput != 'lebonmotdepasse':
    mdpUserInput = input('Saisissez votre mot de passe :')
    nbrAttempts  +=1

print ('Accès autorisé au bout de ', nbrAttempts, 'tentative(s).')

Pas besoin d'un break. C'est une question d'analyse. La boucle doit être effectuée au minimum une fois. Donc affectation à l'avance et déclaration d'une valeur fausse qui entre obligatoirement dans la boucle. Puis input. Pas besoin d'un break et c'est non seulement logique, mais oblige en matière d'algorithme à réfléchir s'il faut toujours entrer dans la boucle (au moins une fois) ou bien s'il y a des cas dans lesquels on ne doit pas y entrer.

Il me semble au contraire que pédagogiquement cette réflexion est intéressante.
Concernant le typage, je persiste que le nommage des variables est la première règle à appliquer pour ne pas se mélanger les pointeurs

[cdang]

Le point 3 n'est pas un souci d'algo, c'est un souci d'absence de "répéter jusqu'à" dans le langage qui oblige à une bidouille "dangereuse" (tout est relatif)

Je veux bien un exemple parce que j'ai toujours réussi à remplacer le repeat... until par des while... do en déterminant le booléen en fin de boucle (mais j'ai peut-être mal compris le problème, et puis je n'ai jamais fait de choses vraiment compliquées).

[Seigneur Ombre]

Je veux bien un exemple parce que j'ai toujours réussi à remplacer le repeat... until par des while... do en déterminant le booléen en fin de boucle (mais j'ai peut-être mal compris le problème, et puis je n'ai jamais fait de choses vraiment compliquées).

Comme je le disais plus haut, le seul cas auquel je pense, c'est du code coté serveur qui écoute un socket.

Pour les "autres cas" j'avoue que je ne vois pas non plus pourquoi il serait impossible de tourner ça autrement.

EDIT - et encore, même dans le cas d'un socket, on se passe du break, l'arrêt passant plus souvent par un keyboard interrupt.

[cdang]

Hé, moi j'ai appris qu'on mettait un $ au nom de la variable si c'était une chaîne de caractères ! Et que GOSUB c'était mieux que GOTO.

[Hermi]

Je veux bien un exemple parce que j'ai toujours réussi à remplacer le repeat... until par des while... do en déterminant le booléen en fin de boucle (mais j'ai peut-être mal compris le problème, et puis je n'ai jamais fait de choses vraiment compliquées).

repeat ... until va exécuter la boucle au moins une fois, ce qui n'est pas le cas de while ... . D'où la tentation d'écrire :

Code : Tout sélectionner

while True:
    ...
    if condition:
        break

[cdang]

Bah si, comme dit par Seigneur d'Ombre, si tu initialises ton booléen à vrai avant la boucle, elle s'exécute au moins une fois.

[rougepied]

Je veux bien un exemple parce que j'ai toujours réussi à remplacer le repeat... until par des while... do en déterminant le booléen en fin de boucle (mais j'ai peut-être mal compris le problème, et puis je n'ai jamais fait de choses vraiment compliquées).

repeat ... until va exécuter la boucle au moins une fois, ce qui n'est pas le cas de while ... . D'où la tentation d'écrire :

Code : Tout sélectionner

while True:
    ...
    if condition:
        break

Toutes les instructions comme until, while, do until et do while, ce n’est que du sucre syntaxique sur l’instruction for. Je crois que la démonstration était déjà faite dans le Kernighan & Ritchie. C’en est à un point que les concepteurs du langage Go ont carrément décidé de ne mettre que la boucle for dans le langage.

Ça me semble assez révélateur que tout ceci est pour moi plus un problème dû à l’absence de bonnes pratique dont l’enseignement devraient préexister à l’enseignement du langage de programmation, quel qu’il soit. Après mes 6 premiers mois de travail de dev je me suis vu dire « c’est quoi cette merde » devant du code avant de m’apercevoir que c’était le premier que j’ai pondu.
Et je fais encore le même constat en relisant les PR des développeurs juniors qu’on m’envoie. C’est pas un problème de maitrise du code dans un langage trop laxiste, c’est un problème de maitrise des risques par des gens à qui on n’a pas expliquer pourquoi on fais ci et pas ça. Et ce n’est pas forcément au langage de forcer la main. Ou alors il faut ne plus faire que du Rust (et pourtant j’adore le Rust).

[Seigneur Ombre]

Toutes les instructions comme until, while, do until et do while, ce n’est que du sucre syntaxique sur l’instruction for. Je crois que la démonstration était déjà faite dans le Kernighan & Ritchie. C’en est à un point que les concepteurs du langage Go ont carrément décidé de ne mettre que la boucle for dans le langage.

Ça me semble assez révélateur que tout ceci est pour moi plus un problème dû à l’absence de bonnes pratique dont l’enseignement devraient préexister à l’enseignement du langage de programmation, quel qu’il soit. Après mes 6 premiers mois de travail de dev je me suis vu dire « c’est quoi cette merde » devant du code avant de m’apercevoir que c’était le premier que j’ai pondu.
Et je fais encore le même constat en relisant les PR des développeurs juniors qu’on m’envoie. C’est pas un problème de maitrise du code dans un langage trop laxiste, c’est un problème de maitrise des risques par des gens à qui on n’a pas expliquer pourquoi on fais ci et pas ça. Et ce n’est pas forcément au langage de forcer la main. Ou alors il faut ne plus faire que du Rust (et pourtant j’adore le Rust).

Je plussoie fortement.

On pense en premier à ce qu'on doit faire et pourquoi, et ensuite on passe au comment, cad quelle syntaxe la plus appropriée on va utiliser.

[Cryoban]

Ou alors il faut ne plus faire que du Rust (

Ca a quoi de spécial RUST?

[XO de Vorcen]

Perso j'utilise DOW (do while (condition)) et DOU (do until (condition)) selon mon besoin (devoir passer une fois ou pas dans la boucle, contrainte fonctionnelle ou technique).
Mais dans le langage que je maîtrise le mieux (le RPG d'IBM i), la condition reste en entête de boucle, pas en fin. Ce que je trouve humainement plus clair à lire :

DOW (condition);
  instruction;
  instruction;
  ...
ENDDO;

et strictement idem avec DOU

[rougepied]

Ca a quoi de spécial RUST?

Rust c’est plutôt orienté bas niveau. Ça a été créé par Mozilla pour re-développer le moteur de Firefox et éviter les seg falt.

La grosse particularité de Rust (le langage, pas le JV) c’est de se vouloir sécurisé en contraignant fortement le contrôle des variables. En plus du typage fort, il y a une notion de possession et d’emprunt de celles-ci : à n’importe quel moment du code, il n’y a qu’un seul responsable d’une variable.
Une autre particularité c’est que, par défaut, tu es un peu obligé de traiter tous les cas de figures. Ou d’explicitement dire que tu ne le fais pas. Par exemple, si tu veux lister le contenu un répertoire, soit ça marche, soit ça marche pas (répertoire inexistant, pas les droits en lecture…). En Rust, ça te retourne un enum Rust avec le cas où ça marche et le cas où ça marche pas. Et c’est à toi de traiter chacun.

(Pseudo code, hein, je sais pas si c’est correct. J’ai pas fait de Rust depuis longtemps et je suis pas un cador)

Code : Tout sélectionner

let readResult = fs::read_dir("./"); /* retourne un Result<ReadDir> qui retourne un enum avec Ok() ou Err */
match readResult {
    Ok(path) => {
        /* traitement du cas où ça marche. On récupère un Iterator sur le contenu du répertoire */
        for path in paths {
            println!("Name: {}", path.unwrap().path().display())
        }
    },
    Err(e) => {
        /* traitement du cas où ça ne marcherait pas */
    },
}

Si tu ne fais pas ça, le compilo t’envoie promener.

L’autre solution, c’est de dire explicitement au compilo « tkt, je gère, ça plantera pas » et si ça plante, bah le programme s’arrête et c’est bien fait pour toi. Mais ni toi ni le langage ne peuvent présupposer que ça va bien se passer.

Code : Tout sélectionner

let paths = fs::read_dir("./").unwrap(); /* avec le unwrap, on ne récupère directement l’Iterator si tout se passe bien. Sinon KABOOM! */

for path in paths {
    println!("Name: {}", path.unwrap().path().display())
}

[Cryoban]

Merci pour l'explication. Un peu fastidieux à coder, mais une fois que c'est fait c'est probablement assez béton.

[mithriel]

En langage pédagogique, Pascal est pas mal, mais je reste fan d'Eiffel. Par contre, pour convaincre les gens d'apprendre ça...

Certes.

@Seigneur Ombre Ta bidouille est mieux qu'un break, mais c'est toujours moins lisible qu'un répéter jusqu'à bien propre. C'est l'absence de répéter qui m'emmerde (surtout pour mes débutants, les informaticiens, je leur explique et ça passe crème) et l'obligation de trouver une bidouille plutôt que la bidouille elle-même.

@rougepied C'est plutôt le for en C qui est un while. Le for de base (de 1 à n et variantes) ne fait pas tout ce que fait un while, tandis que l'inverse est vrai.

On pense en premier à ce qu'on doit faire et pourquoi, et ensuite on passe au comment, cad quelle syntaxe la plus appropriée on va utiliser.

On est d'accord, mais encore ce matin, j'ai entendu un "boucle si".

[Seigneur Ombre]

@mithriel Mouis, donc réfléchir à la logique du pourquoi et la bonne nomenclature du comment, c'est de la bidouille... Désolé, mais je pense que la conversation s'arrêtera ici en ce qui me concerne.

Bon WE à toi

[mithriel]

Faut pas le prendre mal, la bidouille, c'est comme les bons et les mauvais chasseurs. Euh, mauvais exemple. Une bonne astuce/bidouille, c'est bien. Je reformule encore : être obligé d'écrire un répéter jusqu'à autrement qu'avec une syntaxe répéter jusqu'à n'est pas génial à des fins d'apprentissage du tout premier langage par des débutants.