Réduire la quantité de ligne de code c'est effectivement élégant ; mais ça ne veut pas forcément dire faire du code optimisé en CPU ou mémoire : les dicos et listes ont un coût non négligeable ! D'expérience, faire du code un peu plus "explicite" (donc plus bavard) permet très souvent de lever des ambiguïtés sans nécessairement avoir du code sous-optimal ; en plus ça permet aussi aux autres (ou à soi-même, des années plus tard !) de pouvoir lire et comprendre le code facilement et de voir ses possibles bugs (ou features, comme on dit dans le jargon :-) ).
Bonjour. Sans compter que ça va noyer tous les débutants,voire faux débutants. Vidéo qui est pour un niveau intermédiaire en programmation.mon prof faisait ça aussi :nous chier des corrections avec du code optimisé (pour se la péter) alors que nous étions débutants...quel bordel dans nos têtes....
Merci pour cette vidéo très limpide et lisible. Petite astuce dans l'astuce: utiliser `country in {"fr", "en", "it"}` est environ 40% plus rapide avec un set qu'avec une liste.
Il y a de très bons conseils, mais pour l'opérateur or je suis mitigé. En effet le code est plus court mais on pourrait penser que value va prendre une valeur booléenne (le résultat de la condition user_input or default_value) La réduction du nombre de lignes de code ne doit selon moi pas se faire en rognant sur la lisibilité du code ;).
Bonjour. Sur les dictionnaires pour les conditions, existe-t-il une possibilité d'ajouter les paramètres aux fonctions que l'on souhaite placer dans les valeurs ? ex: "delete" : delete_user(user, id) Je vous remercie vivement pour la réponse.
@@Docstring Et bien, dans le dictionnaire que vous créez, on a bien des noms de fonctions qui sont "stockés" dans les valeurs. Et pour ensuite, utiliser ces fonctions, on récupère donc ces libellés par la variable que vous appelez func à laquelle on appose ensuite deux parenthèses. Peut on faire la même chose, c'est à dire stocker mes noms de fonctions dans un dictionnaire mais avec les paramètres qui vont avec ? Pardon pour mes mots qui ne sont certainement pas les bons mais je vous présente un exemple: dico = { 1: etude_voiture, 2: etude_ecurie, 3: etude_sponsors} func =d.get(event) func =() mais peut-on imaginer une manière des stocker des fonctions avec paramètres et un moyen de les appeler: dico = { 1: etude_voiture (moteur, couleur, carburant, nbcourses), 2: etude_ecurie (proprietaire, nbpilotes), 3: etude_sponsors (capitaux) } ?
Je pense que si tu gardes des noms de variables explicites, le code reste quand même assez facile à comprendre. Peut-être moins pour un débutant complet, mais à un moment, il faut trouver des moyens d'optimiser le code un minimum tout en s'assurant de ne non plus tomber dans l'effet inverse en faisant des lignes de 400 caractères. Si en mettant en œuvre ces optimisations ton code est incompréhensible, j'aurais tendance à penser que le problème se trouve ailleurs.
@@Docstring Je ne dis pas qu'ils ne faut pas les utiliser. J'appelle juste à la prudence. Ensuite il y a un deuxième argument en leur défaveur c'est celui des tests unitaires. En effet en utilisant ce genre d'astuces on a plus de mal à savoir le nombre de tests unitaire à écrire dans certains cas.
@@MichelSLAGMULDER Bien sûr, un code doit de toute façon être pensé de façon cohérente dans son ensemble, il ne s'agit jamais d'appliquer des règles, chaque cas est particulier. Mais quand je vois des structures conditionnelles avec un if expression: return True else return False par exemple, je ne vois vraiment pas l'intérêt d'écrire ces 4 lignes de code. Ça ne change absolument rien par rapport aux tests, car dans les deux cas tu retournes la même chose. C'est peut-être plus facile à lire pour un débutant (et il m'arrive dans mes formations de volontairement décomposer le code ainsi), mais à terme je trouve vraiment que c'est redondant.
Réduire la quantité de ligne de code c'est effectivement élégant ; mais ça ne veut pas forcément dire faire du code optimisé en CPU ou mémoire : les dicos et listes ont un coût non négligeable !
D'expérience, faire du code un peu plus "explicite" (donc plus bavard) permet très souvent de lever des ambiguïtés sans nécessairement avoir du code sous-optimal ; en plus ça permet aussi aux autres (ou à soi-même, des années plus tard !) de pouvoir lire et comprendre le code facilement et de voir ses possibles bugs (ou features, comme on dit dans le jargon :-) ).
Bonne remarque
Bonjour. Sans compter que ça va noyer tous les débutants,voire faux débutants. Vidéo qui est pour un niveau intermédiaire en programmation.mon prof faisait ça aussi :nous chier des corrections avec du code optimisé (pour se la péter) alors que nous étions débutants...quel bordel dans nos têtes....
De vrais de conseil!!! Merci Docstrings!
Merci pour cette vidéo très limpide et lisible.
Petite astuce dans l'astuce: utiliser `country in {"fr", "en", "it"}` est environ 40% plus rapide avec un set qu'avec une liste.
Merci Thibault !! très bonne idée ce format vidéo d'astuces ;)
Vraiment très fort. Merci beaucoup.
Très pertinent (comme d'habitude). Merci !
Youhou ! Notre maître nous donne d'excellents conseils à appliquer dans nos projetsrespêctifs. Merci Thib'.
Merci beaucoup pour cette excellente vidéo 🙏🙏.
Mercii Thibault ...
Pour ses précieux conseils
;)
j'adore,
je viens d'avoir une pub docstring juste avant la vidéo 🤣
Bonjour, quel éditeur de code utilise tu ??
Merci
Youhou 🎉
Merci 🔥
Il y a de très bons conseils, mais pour l'opérateur or je suis mitigé.
En effet le code est plus court mais on pourrait penser que value va prendre une valeur booléenne (le résultat de la condition user_input or default_value)
La réduction du nombre de lignes de code ne doit selon moi pas se faire en rognant sur la lisibilité du code ;).
Bonjour. Sur les dictionnaires pour les conditions, existe-t-il une possibilité d'ajouter les paramètres aux fonctions que l'on souhaite placer dans les valeurs ? ex: "delete" : delete_user(user, id) Je vous remercie vivement pour la réponse.
Bonjour, je ne suis pas sûr de comprendre votre question. Pour les conditions = structures conditionnelles? Paramètres au fonction = quelle fonction ?
@@Docstring Et bien, dans le dictionnaire que vous créez, on a bien des noms de fonctions qui sont "stockés" dans les valeurs. Et pour ensuite, utiliser ces fonctions, on récupère donc ces libellés par la variable que vous appelez func à laquelle on appose ensuite deux parenthèses.
Peut on faire la même chose, c'est à dire stocker mes noms de fonctions dans un dictionnaire mais avec les paramètres qui vont avec ? Pardon pour mes mots qui ne sont certainement pas les bons mais je vous présente un exemple:
dico = { 1: etude_voiture,
2: etude_ecurie,
3: etude_sponsors}
func =d.get(event)
func =()
mais peut-on imaginer une manière des stocker des fonctions avec paramètres
et un moyen de les appeler:
dico = { 1: etude_voiture (moteur, couleur, carburant, nbcourses),
2: etude_ecurie (proprietaire, nbpilotes),
3: etude_sponsors (capitaux)
}
?
Je viens de regarder la première partie. Va falloir que j'applique ça j'ai tendance à trop développer avec beaucoup de lignes lol
Super vidéo à toi Thibault. Mais avec l'arrivé de Switch en python je pense qu'il peut faire l'affaire dans le 5ème astuce.
Merci ! En effet, le switch arrive bientôt !
Bonjour. Vidéo qui n'est pas pour un débutant mais plutôt niveau intermédiaire (ou proche).
De bonnes astuces que j'espère utilisées, J'ai aussi trouver celle-ci : print("good" if variable else "bad")
Pourquoi ne pas mettre une seule ligne ? "value = input(question) or default_value "
On peut toujours faire plus court ;) Ici on pourrait avoir envie de faire des vérifications sur la saisie de l'utilisateur entre les deux par exemple.
Je me sens nul à pas face à la console vide..
Faut faire attention à ce genre d'astuces car elles rendent le code plus difficile à comprendre.
Je pense que si tu gardes des noms de variables explicites, le code reste quand même assez facile à comprendre. Peut-être moins pour un débutant complet, mais à un moment, il faut trouver des moyens d'optimiser le code un minimum tout en s'assurant de ne non plus tomber dans l'effet inverse en faisant des lignes de 400 caractères.
Si en mettant en œuvre ces optimisations ton code est incompréhensible, j'aurais tendance à penser que le problème se trouve ailleurs.
@@Docstring Je ne dis pas qu'ils ne faut pas les utiliser. J'appelle juste à la prudence. Ensuite il y a un deuxième argument en leur défaveur c'est celui des tests unitaires. En effet en utilisant ce genre d'astuces on a plus de mal à savoir le nombre de tests unitaire à écrire dans certains cas.
@@MichelSLAGMULDER Bien sûr, un code doit de toute façon être pensé de façon cohérente dans son ensemble, il ne s'agit jamais d'appliquer des règles, chaque cas est particulier.
Mais quand je vois des structures conditionnelles avec un if expression: return True else return False par exemple, je ne vois vraiment pas l'intérêt d'écrire ces 4 lignes de code. Ça ne change absolument rien par rapport aux tests, car dans les deux cas tu retournes la même chose. C'est peut-être plus facile à lire pour un débutant (et il m'arrive dans mes formations de volontairement décomposer le code ainsi), mais à terme je trouve vraiment que c'est redondant.