Alors, cette série te plaît ? N'hésite pas à nous dire ce que tu modifierais dans le code des étudiants 👇
@dsggk2 жыл бұрын
Super épisode, merci beaucoup 🙏🏾
@jonathandufour86212 жыл бұрын
Je l'aurais fait en C, avec une lookup table pour le menu, et un arbre binaire rouge et noir pour la liste de courses, ou bien une hashmap 🙃
@ambdil-kayoummohamed84202 жыл бұрын
Propre, un format magnifique j’adore. J’étais justement en train de chercher comment fonctionne le mot « CONTINUE ». Vous venez de me l’apprendre, comme d’habitude on apprend toujours des nouvelles choses à chaque vidéo. Continue comme ça. continue 😅
@Docstring2 жыл бұрын
Merci!! Super content de voir que tu as appris de nouvelles choses 🤩🥳
@AlexandreMalfreyt2 жыл бұрын
L'extension "Sourcery" pour VS Code est ultra pratique pour ce genre d'inattentions, je l'avais découverte dans ta vidéo sur les 5 extensions indispensables 😁
@Docstring2 жыл бұрын
Oui exact!
@Masta_lingo2 ай бұрын
Je viens de te découvrir, simple et claire comme explication ✨ Je m'abonne.
@ekhaion32962 жыл бұрын
Merci pour tes vidéos ainsi que tes formations qui sont très bien faîtes et agréable à suivre 🙂
@Docstring2 жыл бұрын
Merci 😌☺️
@okomiya54012 жыл бұрын
Pour la plupart des corrections (j'ai survoler les dernieres), la condition du choix invalide peut se mettre à la fin des autres conditions avec simplement un else.
@nouroudinesoumanahama70062 жыл бұрын
Merci beaucoup pour les formations, tu me donnes réellement envie de coder
@Docstring2 жыл бұрын
Merci pour ton commentaire, ça fait plaisir 🤩
@corentinvillemus14572 жыл бұрын
Hello, jamais fait de Python = assez perturbé par les semi-columns 404. Je bosse depuis 2 ans dans le milieu et franchement, sympa comme vidéo à avoir en fond :). Je vais de ce pas aller voir ce que tu as dans le même genre d'accessible for All. Je cherche des thèmes genre : Quand passer par un Design Pattern, Objets ou Variables ? Classes ou pas besoin ? etc.
@daviddecherf84342 жыл бұрын
Exellent! au moment où je fait l'exercice! Bravo!
@deata55132 жыл бұрын
Les sous titre sont juste géniaux.
@Docstring2 жыл бұрын
J’avoue, ils ont fumé !
@Linkdu-pp5nl2 жыл бұрын
Vraiment intéressant de voir ta façon de raisonner ! Quelque question : 1 - Quand on veut vider une liste, vaut t'il mieux faire ma_list.clear() ou ma_list = [] ? Ou c'est la même chose fonctionnellement ? 2 - Qu'en penses tu de passer par un dictionnaire pour remplacer toute les strings qui sont dans dans print ? Par exemple : statut_dict = { "choice_menu": "faite votre choix", "add_product": "produit a ajouter", "quit": "vous avez quitter le programme", } Alors oui dans ce genre de cas, avec tout les condition, ça fait un gros pathé et ça serait mieux qu'il y ai un fichier juste pour le dictionnaire complet ^^ Mais ça rajouterai de la visibilité dans le code je trouve
@RisingSunLightRSL2 жыл бұрын
[] assigne une nouvelle liste vide à la variable, tandis que clear() supprime réellement tous les éléments de la liste. Cela peut causer des problèmes lorsque 2 variables pointent sur la même liste. Si tu fais clear() sur l'une, l'autre sera aussi vide, si tu assignes [], l'une sera vide, l'autre non (car l'autre existe toujours, c'est juste qu'elle n'est plus pointée). Si on devait optimiser la mémoire, clear() est mieux car on ne recrée pas de liste à chaque fois, laissant des listes non pointées derrière (même si elles finiraient par se faire virer de la mémoire)
2 жыл бұрын
@@RisingSunLightRSL Par ailleurs, à mon sens, l'autre avantage d'utiliser "clear" est tout simplement d'être explicite sur l'intention (indiquant clairement que a) on s'attend à agir sur une liste non vide b) on veut bel et bien la vider entièrement). C'est un détail sur des codes simples comme ça, mais quand les scripts se complexifient en centaines de lignes sans pour autant être réécrits en forme fonctionnelle, il devient plus difficile de mémoriser les "points d'affectation et d'usage" de chaque variable. D'où l'intérêt de distinguer immédiatement "affectation d'une liste vide" (qui pourrait être une initialisation de variable) de "vidange d'une liste par clear". AMHA.
@clementguyard91302 жыл бұрын
Trop propre ton code c'est fou
@alownseul61912 жыл бұрын
Déja 1ere remarque => le 1er script ne fonctionne pas .... ??? Qui a envoyé un code qui ne fonctionnais aps ? genre, faut appeller la police la.
@Dante-qf7dk2 жыл бұрын
Moi j'ai une question : faut-il faire du pseudo code avant de commencer à programmer car je suis étudiant et le professeur dis que c'est la clé pour pouvoir après le retranscrire dans n'importe quel langage. Je sais pas si tu as déjà abordé ce sujet dans une vidéo. J'aimerais avoir des conseils pour comment avoir le déclic en logique et programmation afin de créé du pseudo code sur feuille puis le taper sur la machine
@Docstring2 жыл бұрын
Salut ! C’est une bonne étape à réaliser après ça dépend le programme et ton niveau, ce n’est pas non plus une nécessité absolue. Poser par écrit les bases de ce que tu veux faire c’est important après pas besoin non plus de faire l’intégralité de ton script en pseudo code avant de te lancer.
@Zeke3282 жыл бұрын
À 11:38, il fait comment pour dupliquer la ligne sans la sélectionner svp?
@Docstring2 жыл бұрын
De mémoire c’est alt + shift et flèche du bas (ou Control / cmd + shift)
@Docstring2 жыл бұрын
www.google.fr/search?q=visual+studio+code+duplicate+line&ie=UTF-8&oe=UTF-8&hl=fr-fr Et hop une petite recherche Google et tu as ta réponse 😜
@Zeke3282 жыл бұрын
@@Docstring Merci bien ! 🙏
@sitrakaforler86962 жыл бұрын
Vraiment utile ! Top!
@Docstring2 жыл бұрын
Mercii ! Content que le format plaise :)
@kiadyravel9752 жыл бұрын
En tant que developpeur confirmé, je ne suis pas très fan des imbrications de else if, on aurait pu utiliser les hmap et faire un try catch pour verifier si l'entré est bien un int etc...
@Docstring2 жыл бұрын
Effectivement, il y a plein de façons de rendre ce script plus pro, j'ai oublié de présenter plus en détail l'exercice et le moment à partir duquel il apparaît dans la formation (tout au début, après l'introduction des structures conditionnelles). L'objectif ici n'est donc pas de changer le code du tout au tout en faisant quelque chose de beaucoup plus optimisé mais qu'un débutant ne comprendrait plus, mais juste de prendre le code existant et de l'améliorer le plus possible en gardant l'idée de base du code :)
@kiadyravel9752 жыл бұрын
@@Docstring je comprends mieux, merci
@electronicinfo98322 жыл бұрын
j'ai réalisé un programme avec factorisation du code je ne sait pas ou le poster pour que tout les abandonnés en profite après correction de ce code de votre pars
@Docstring2 жыл бұрын
Salut ! Tu peux le poster directement ici, sinon dans un Gist pour qu'on ait un meilleur affichage, ou tu peux nous rejoindre sur le serveur Discord :)
@adam44782 жыл бұрын
Attention, 40:26 ce code : if not choice.isdigit() and int(choice) > 1 : print("Invalid") else : print("Valid") ne donne pas le même résultat que celui là : if not (choice.isdigit() and int(choice) > 1) : print("Invalid") else : print("Valid") Pour s'en convaincre on peut tester avec choice = "test" ou encore choice = "0" En réalité, la négation agit comme ça : non(A et B) = non(A) ou non(B), le "et" devient un "ou"
@Docstring2 жыл бұрын
Bien vu Adam, je suis allé vite sur cette partie, c'est la loi de De Morgan, et effectivement ça ne fonctionne pas du coup. Désolé pour l'imprécision !
@adam44782 жыл бұрын
@@Docstring c'est bien ça ! Sinon excellente vidéo
@MrGueckmooh2 жыл бұрын
Par rapport à la correction sur le check d'intervalle (autour des 6 minutes) je pense qu'il aurait été de bon goût de dire que c'est une construction python qui ne se retrouve pas dans tous les langages, et qui est une GROSSE source d'erreur pour les débutant-e-s quand iels apprennent le C/C++ par exemple Si on écrit la même chose en C on aurait `1
@Overdrink72 жыл бұрын
Effectivement
@AlexandreMalfreyt2 жыл бұрын
Pourquoi ne pas passer à Python 3.10 avec les match cases ? Tu penses que c'est encore trop tôt ?
@Docstring2 жыл бұрын
Non, je compte bien montrer une version de ce script avec les match case :) après historiquement je l'avais fait avec le classique if else et je pense que ça reste un exercice sympa pour mettre en pratique les structures conditionnelles
@remib2422 жыл бұрын
Tu peux même aller encore plus loin, une liste de fonctions, dans chacune d'elle un docstring qui te sert de texte pour remplir ton menu. J'ai eu même poussé le vis plus loin à une époque, en utilisant l'introspection, quand tu rajoutais une méthode à une classe, cela t'ajoutais automatiquement un élément dans un menu tkinter, et les paramètres de chaque méthode, permettait d'ouvrir une boite de dialogue contenant la liste des params de la méthode avec deux boutons ok cancel. Sinon très bon tuto pour débutant.
@Docstring2 жыл бұрын
Ah mais clairement on peut faire des trucs 10,000 fois plus poussés ^^ ! En commençant par rajouter une interface effectivement :)
@corentin241019962 жыл бұрын
Petite question pour la correction 1, n’était il pas envisageable de passer par un switch case? Il faut que la version de python l’accepte bien entendu 😊
@baptistelacourt84342 жыл бұрын
Ça n'existe pas en python malheureusement
@Docstring2 жыл бұрын
Ça existe depuis la version 3.10 (match case mais c'est le même principe que switch case) Dans le cadre de cet exercice, il arrive dans la formation après la présentation des structures conditionnelles. D'où leur utilisation dans ce contexte. L'utilisation des match case pourrait fonctionner également, après je ne pense pas qu'il y aurait une énorme plus-value dans cet exemple.
@arthur11121322 жыл бұрын
@@Docstring vue le petit nombre de cas et le fait qu'ils soient tous contigus (dans la range 1-5) ça devrait pas avoir beaucoup d'impact sur les perf (en considérant que c'est implémenté dans python via un switch C et que c'est pas une feature totalement interprétée) Je connais très peu python, mais en C, le switch va surtout être avantageux quand il y a beaucoup de cas, ou alors quand les cas ne sont pas contigus (1, 9, 17, 22, 36 par exemple). Ca m'es aussi déjà arrivé de préférer un switch pour exploiter le falltrough. Pour pousser la réflexion, pour cet exercice, je pense que (si ça existe en python) un tableau de fonction aurait été plus adapté qu'un switch (bien que probablement hors sujet vis-à-vis du but de l'exercice qui vise clairement à faire comprendre les structures conditionnelles).
@hunzi44362 жыл бұрын
Dans le premier exercice, l'utilisation d'un match case aurait été pratique
@Docstring2 жыл бұрын
Effectivement! Parfait exemple dans lequel le match case serait une bonne alternative! Ce n'est encore pas un réflexe pour beaucoup de développeurs je pense. Mais je commence à utiliser l'opérateur walrus assez souvent et j'ai failli en parler ici d'ailleurs. On va s'y faire petit à petit à toutes ces nouveautés 😄
@hunzi44362 жыл бұрын
@@Docstring L'opérateur walrus est en effet un bon moyen d'améliorer la lisibilité du code tout en réduisant sa complexité ! C'est clair qu'en programmation, il faut toujours être à l'affût de chaque nouveauté 😁
@Docstring2 жыл бұрын
@@hunzi4436 Effectivement après là ils nous en ont sorti tellement en 2-3 versions, on était pas habitué les pythoneux 😂C'est pas JavaScript et npm ici 😅
@impelcode33812 жыл бұрын
@@Docstring Oh ca nous taille
@Docstring2 жыл бұрын
@@impelcode3381 🤭🤫🤐
@gargaranza2 жыл бұрын
La vidéo est très bien, et l'idée est très bonne, la plupart des conseils sont excellents et, je pense, peuvent aider les débutants. Cependant, j'ai remarqué plusieurs choses qui n'allaient pas dans les conseils données. 1er code : - Il ne faut jamais écrire "1
@Docstring2 жыл бұрын
Salut, merci pour ton commentaire ! Je vais cependant m'inscrire en faux sur plusieurs points. Pour le premier point je peux comprendre effectivement qu'on souhaite faire comme dans d'autres langages. Mais c'est une possibilité offerte par Python, je trouverais dommage d'essayer de se calquer complètement sur d'autres façons de faire. Dans ce cas, il y beaucoup de choses qu'on devrait laisser tomber en Python car le langage n'est pas construit de la même façon que d'autres langages. Sur ce point, c'est donc plus une question de préférence je trouve mais je peux comprendre qu'on préfère être plus explicite. Pour l'espace après les 2 points par contre je ne suis pas d'accord. Déjà je ne suis pas d'accord sur le fait que plus il y a d'espaces plus ça respire. Dans ce cas-ci je trouve ces espaces vraiment superflus et je trouve que ça complexifie la lisibilité. Dans ce cas on peut mettre des espaces et sauter des lignes partout et ça sera vraiment espacé. Mais plus d'espace n'est pas toujours égal à une meilleure lisibilité selon-moi. Et surtout, au delà du subjectif, c'est la PEP-8 qui recommande de ne pas mettre d'espace avant les 2 points : peps.python.org/pep-0008/#whitespace-in-expressions-and-statements Je conseille toujours de suivre les recommandations de la pep-8. Tous les scripts Python que je vois passer n'ont pas d'espaces avant les 2 points, donc ce serait aller à contre courant de tout le monde que d'en rajouter un. Pour le 2e code je suis d'accord avec toi mais j'ai oublié de préciser au début de la vidéo le contexte de l'exercice. À ce stade de la formation les fonctions n'ont pas encore été vues. Il y a beaucoup de choses donc qui pourraient être améliorées et séparées avec des fonctions mais là l'idée était surtout de montrer la boucle while et les différentes options de contrôle comme continue ou break ainsi que les structures conditionnelles. Pour le 4e code, là encore pour les séparateurs c'est assez subjectif. Je trouve qu'une ligne "print(separator)" est tout aussi efficace et facile à comprendre que de devoir copier coller et répéter à chaque fois une longue ligne de caractères. Quant au fait de les laisser, si on veut vraiment laisser du debug je passerais plutôt par le logging que par un if debug, mais là encore ce n'est pas quelque chose qui est vu à ce stade de la formation. Dernier point concernant les noms de variables, je ne suis pas d'accord là encore 😅 Je trouve que jamais des noms de variables ne devraient être aussi peu explicite. Il faut s'habituer à écrire un code clair, et des noms de variables comme msg ou elt ne parlent pas à tout le monde. On n'est plus dans les années 80 avec des écrans minuscules, on peut avoir le luxe de créer des noms de variables plus explicites, et si une ligne devient trop longue, c'est généralement qu'il y a trop de choses en même temps sur la ligne et qu'elle peut être séparée en plusieurs lignes. Mais réduire la surcharge du code et vouloir améliorer la lisibilité en utilisant des noms de variables peu explicites n'est selon moi pas la bonne façon de faire. Une part de subjectif du coup dans le code de chacun bien sûr, mais sur les points spécifiques à la pep-8 je serai plus catégorique ^^ Merci en tout cas pour ton retour d'expérience et ton commentaire qui permettent de confronter les points de vue :) Bonne continuation de même !
@qexat2 жыл бұрын
@@Docstring J'ajouterais même que l'idéal serait d'utiliser les breakpoints, c'est une fonctionnalité qu'on retrouve dans la plupart des IDE, qui est assez simple à comprendre et qui évite les print() superflus.
@Docstring2 жыл бұрын
@@qexat Effectivement, après je pense que dans certains cas un print peut encore être intéressant, j'en parlais dans cette vidéo : kzbin.info/www/bejne/iaSaZJVqfJqol6M Le problème du debug c'est que ça peut quand même varier d'un éditeur à un autre, même si les concepts restent les mêmes. Un print pour des scripts très simple de ce genre, perso ça ne me dérange pas et ça évite de perdre pas mal de gens qui ne sont pas à l'aise avec un débugueur. Mais dans une formation complète effectivement c'est un outil indispensable.
@jbhappy22 жыл бұрын
Très bonne vidéo. Petite question dans la première correction c'est pas plus pratique a la place de mettre "if not 1
@Docstring2 жыл бұрын
Oui ça marche aussi ! C’est peut-être juste moins explicite. Avec le else tu peux avoir des effets de bords non prévus dans certains cas. Si tu sais vraiment la condition dans laquelle tu veux exécuter l’action, autant la mettre de façon explicite. Le else est quand même plutôt à privilégier pour toutes les autres actions que tu n’aurais pas prévues.
@Docstring2 жыл бұрын
Je rappelle un des mantra de Python : explicit is better than implicit :)
@dylan-j-gerrits2 жыл бұрын
Intéressant. Cela dit, dommage de ne pas avoir corrigé des cas plus originaux.
@Docstring2 жыл бұрын
Effectivement mais il n'y en avait pas vraiment de bien plus originaux que ça. Le script 3 par exemple était assez original avec ses différentes structures. Mais je garde ça en tête oui pour les prochains, j'essaie toujours de trouver des cas de figure intéressants à corriger :)
@primity6262 жыл бұрын
Cmt il duplique a 11min ?
@Docstring2 жыл бұрын
Une petite recherche sur google et tu as la réponse :) Sur Mac : option + shift + flèche du haut / bas. Si tu es sur Windows ou Linux... je te laisse faire tes recherches ;)
@eldo64beat782 жыл бұрын
Je ne savais pas que tu faisais des corrections pour ce script. J'avais le même aussi, et j'ai fait plus ou moins la troisième version. Mais j'aurais aimé participer. Perso j'ai surtout appris sur les conventions (les espaces). Pour le reste je trouve que je suis un bon élève. La logique y est on va dire à 75% 80%. Je suppose que la partie fonction n'entre pas encore en compte... Pck dans mon script j'ai utilisé des fonctions (peut-être un peu de triche😋)
@Docstring2 жыл бұрын
Salut Étienne! J'ai choisi de faire des corrections générales sur les différents exercices des formations. Sur Udemy il y a plus de 50,000 scripts qui ont été soumis au total sur les différents projets donc je ne peux pas faire de correction individuelle mais de toute façon ce sont souvent les mêmes erreurs qui reviennent. Et oui effectivement pas encore de fonctions à ce stade ci de la formation, je préciserai les notions vues pour les prochaines vidéos :)
@eldo64beat782 жыл бұрын
@@Docstring merci bien. J'apprécie beaucoup la chaîne et le contenu me convient parfaitement. J'ai juste trouvé que ça allait un peu vite vers la fin, je ne voyais pas toutes les manipulations. Mais je comprenqis quand même. Ta pédagogie est au point. Merci encore
@lecerfvolant32962 жыл бұрын
c'est quoi ton thème vs ?
@Docstring2 жыл бұрын
Material theme ocean high contrast :)
@mathiasf63072 жыл бұрын
C'est pas mal mais c'est spécifique à python. Une approche plus algorithmique et optimisée sera mieux. Ex: if len(liste)==0 est préférable à if liste
@Docstring2 жыл бұрын
Effectivement, mais il me semble normal d'utiliser les possibilités du langage. Sinon on calque des façons de faire d'un langage sur un autre et on se retrouve à tous coder comme si on faisait du C, non ? Je n'ai jamais vu un script Python professionnel utiliser la syntaxe if len(liste) == 0, c'est pour moi redondant et je sais que Python est capable de comprendre la syntaxe simplifiée de if liste et je pense que dans ce contexte c'est donc préférable.
@henrichabert69162 жыл бұрын
Hello docstring ! Alors je suis un peu d’accord avec le fait que len(liste) == 0 est mieux que not list car l’explicite est souvent mieux que l’implicite. Vu que python est un langage non typé, “liste” pourrait être une chaîne de caractères, un None, ou tout autre objet, qui s’évaluerait a “False” avec “If liste”. Écrire “len(liste) == 0” signifie au lecteur du code que l’on sait que cet objet est une liste. J’avais le même avis que toi il y a quelques temps mais j’ai changé d’avis après avoir review et vu pas mal d’erreurs sur cette question :) En tout cas super vidéo pour les débutants, bravo !
@Docstring2 жыл бұрын
@@henrichabert6916 Salut Henri et merci pour ton retour ! Je comprends ton point de vue mais je reste convaincu qu'il est préférable de ne pas utiliser len (et je vais rajouter quelques arguments 😄). Tout d'abord, sur le fait que l'explicite est mieux que l'implicite, je suis tout à fait d'accord, mais la phrase qui suit celle-ci dans le PEP-20 / zen of python est "Simple is better than complex". Dans un cas comme celui-ci les deux principes peuvent se confronter l'un à l'autre, mais j'ai de mon côté bien plus souvent vu du code pro utiliser directement le concept de "truth value testing" que l'utilisation de len. C'est d'ailleurs une recommandation de la PEP-8 (peps.python.org/pep-0008/#programming-recommendations). Par rapport au fait que liste pourrait être n'importe quel type d'objet, je suis d'accord, mais il me semble que le problème reste le même. L'utilisation de len sur certains objets poserait d'ailleurs une erreur (len(None) par exemple), donc il faudrait de toute façon s'assurer au préalable d'avoir le bon type de données pour éviter ce problème. En tout cas, je comprends le débat qu'il peut y avoir et dans un cas comme dans l'autre ce n'est pas dramatique, personnellement je n'ai jamais eu aucun soucis dans mes scripts et ceux de mes collègues en utilisant le "truth value testing" qui fonctionne pour tous les types natifs et qui permet d'alléger le code. Merci en tout cas pour tes réflexions et au plaisir !
@bishop69032 жыл бұрын
Les gens ne mettent jamais de fonctions dans leurs programmes histoire de partitionner le code et le rendre plus facile à lire et plus opti ?
@Docstring2 жыл бұрын
J'ai oublié de le mentionner mais cet exercice arrive à un moment dans la formation où les fonctions n'ont pas encore été vues. Et le projet revient par la suite avec différentes approches notamment une approche orientée objet. J'aurai l'occasion donc de faire d'autres vidéos sur le sujet avec ces exercices et je prendrai soin de mentionner ces précisions qui ont leur importance.
@tbremard2 жыл бұрын
while action != ACTION_QUIT
@muaythai75342 жыл бұрын
Salut Thibault ! J'aurais voulu avoir ton avis selon toi quelle est la roadmap backend idéal ?
@Docstring2 жыл бұрын
Idéal... difficile à répondre, ça dépend de beaucoup de choses, notamment de quel langage tu parles (j'imagine Python ?) Mais django / flask sont des incontournables avec Python.
@scorpiobtw.2 жыл бұрын
bv
@rudyantheus81712 жыл бұрын
j'arrive pas a comprendre pourquoi , alors que tout est écrit en Français, vous nous emmerdez a rajouter des "user input " etc , arrêtez avec l'anglais surtout quand ce n'est pas obligatoire !!! merci
@Docstring2 жыл бұрын
Désolé mais le milieu du développement est très majoritairement anglophone. Il est conseillé par les développeurs de Python d'écrire en anglais même si l'équipe ne l'est pas pour faciliter la collaboration. Vous pouvez faire le choix de tout écrire en français mais force est de constater que pour les gens qui travaillent en entreprise, ça n'arrivera jamais. Donc autant s'habituer tout de suite. Donc si, désolé mais dans le contexte d'être développeur, l'anglais est obligatoire.
@itsukiichiyuu222 жыл бұрын
Les sous-titres sont devenus fous chez moi o_o
@Docstring2 жыл бұрын
Ils sont générés automatiquement par KZbin donc je n’ai aucun contrôle là dessus 🤷♂️
@desire12622 жыл бұрын
Salut , qui peut m'apprendre a coder en c++ ? Merci
@LiorCHAMLA2 жыл бұрын
En bon Français : la revue/relecture de code ! SALTIMBANQUE VAS !
@Docstring2 жыл бұрын
La revue 🥲 on dirait un vieux magazine genre télé 7 jours.
@FIicher2 жыл бұрын
sous titre sous cocaine
@pilnatosor94992 жыл бұрын
j'ai fait ma version sur le pastebin suivant: dGSA7RZi je pense pas que l'ont puisse faire mieux, hésiter pas a me donner votre avis :D
@jackwolf53632 жыл бұрын
le plus gros soucis de ton code, c'est l'ingérence des actions sur ton objet application : en temps normal les champs liste et is_running sont en privé et des méthodes sont disponibles (dans la classe application) pour pouvoir les manipuler indirectement => il faudrait donc des méthodes add, remove, list, clear pour manipuler la liste ... et une méthode exit pour toucher le flag is_running autre point : le franglais ! ne mélange pas les 2 langues ! je vois ca sur les noms des variables (liste et is_running) et sur le message d'erreur de safe_int_input en anglais qui sort de nulle part ("Clear la liste de course", sérieusement ?) la ligne 61 présuppose que tu utilise select_element pour supprimer un élément, alors que son role est simplement de lister et choisir un élément de la liste (et c'est un truc que l'application doit proposer) => il faut donc déplacer la ligne 61 et l'intercaler entre la 69 et 70