4 ERREURS courantes qui rendent ton code moche (et comment les corriger)

[@denisjean-bastien1253]

Continue! J'adore ! Hâte à la prochaine vidéo ! Et merci pour ce contenu 😊

[@Sql37]

Super, merci !

[@MrWass14]

On va pas se mentir, tu vas aller loin 😉

[@greggs2444]

Salut ! J’ai découvert ta chaîne il y a quelques jours et tu fais un très bon contenu, je t’encourage à continuer comme ça ! Je me reconnais parfois dans les erreurs que tu montres et j’essaie d’améliorer ça dans mon quotidien de dev J’utilise souvent des dataframe pandas dans mon boulet et je me demande s’il vaut mieux nommer mon dataframe df (sachant qu’il évolue au fil du traitement) ou lui donner un nom plus explicite qui change ligne par ligne (exemple : df_raw, df_with_tax, df_to_export, etc.) Merci !

[@greggs2444]

J’ajouterais que parfois un commentaire bien placé m’a aidé à comprendre pourquoi mon prédécesseur avait écrit une ligne (et c’est quasi tout le temps suite à une demande d’un client, donc pas vraiment de logique suffisante pour être retranscrite dans le nom de la variable sans explication)

[@LaMaliceCode]

Hello merci pour ton commentaire ! C'est toujours mieux d'être le plus explicite donc bien nommer son df à chaque fois. Par contre si t'as des problématiques de mémoire, faut penser à delete la variable précédente (del "nom de variable") une fois qu'elle n'est plus utilisée, ainsi de suite. C'est sûr que certains commentaires peuvent être utile dans certains cas ;) , je parle plus des dev qui mettent "trop de commentaires" au lieu d'être explicite dans le code.

[@chihoon_yi]

bg

[@rousquille66]

Hello, merci pour le contenu que tu proposes. Question, les kwargs ont-ils une utilité lorsqu'on applique les principes SOLID (hors décorateurs) ?

[@LaMaliceCode]

Hello merci à toi ! Les kwargs, ça peut être utile surtout pour garder du code flexible (ex: principe Open/Closed) en permettant l’ajout d’arguments optionnels sans modifier l’interface publique. Mais faut pas trop en abuser je pense, sinon ça peut rendre le code moins clair.

[@rousquille66]

@@LaMaliceCode merci 🙂

[@ikonjoou]

Merci d'apprendre les principes d'Oncle Bob aux juniors. ps: La jeune fille à la perle, tournée vers la droite c'est perturbant, si tu pouvais remettre ton image dans le bon sens au montage, ça serait parfait. désolée ;)

[@LaMaliceCode]

N'en dis pas plus j'y ferais attention pour la prochaine vidéo

[@IBelieveInCode]

Intro de la vidéo : "Notre métier de développeur il est complexe, il est difficile..." La suite : des conseils applicables seulement sur des projets faciles... PS : affirmer qu'une fonction de 15 lignes est "trop longue", je ne commente même pas...

[@technologynews3143]

Du coup ca te choque pas d'avoir 200 fonctions par classes ?

[@LaMaliceCode]

J'imagine que si t'as 200 méthodes dans une classe, c'est qu'elle a un problème de single responsibility. Je conseille pour un code lisible, moins de 3 méthodes publiques par classe pas plus. Le nombre de méthodes privés dépendra de la complexité et de chacun évidemment :)

[@IBelieveInCode]

@@LaMaliceCode "J'imagine que si t'as 200 méthodes dans une classe, c'est qu'elle a un problème de single responsibility." Tu n'en sais rien. Faut étudier un peu ce que les gens font si tu veux les conseiller... 200 méthodes publiques ce n'est pas nécessairement délirant. Considère par exemple une classe qui implémente un gros type abstrait de données, ou qui a un rôle clé dans une application (par exemple si une des méthodes de cette classe est une sorte d'ordonnanceur qui constitue la boucle principale du programme).