Re: Pas beau du tout...

Je fais du python au quotidien... et là je suis séché : je n'ai jamais rien lu de si moche !

• Code illisible
• Tout est mélangé
• ...

Je fais du python au quotidien aussi, depuis dix ans, et du code moche on en trouve... et parfois même quand ce n'est pas le premier code écrit (dans le cas du premier jet d'un dév, c'est normal d'avoir du code moche).

D'ailleurs, ça m'arrive encore d'en écrire du code moche : quand tu prototypes rapidement un truc, tu fais pas du code propre (même si tu appliques tes règles de codage dans une certaine mesure)

Pour commencer, python dispose d'un mécanisme de namespace qui permet de séparer les trucs dans des distincts:

• les modules : de simples fichiers python qui permettent de séparer le code, importables.
• des packages : des dossiers contenant (au moins) un fichier init.py, importables.

Ces 2 trucs permettent de séparer les choses dans des espaces distincts, et éviter les scripts à ralonge.

Je vais me faire l'avocat du diable, mais parfois les scripts à rallonge se justifient. Si tu écrits des scripts, justement, l'intérêt d'avoir un script à rallonge c'est d'avoir un outil indépendant. Tout comme Go génère un binaire qui contient tout. A déployer, c'est de la rigolade par rapport à un logiciel qui est bien structuré.

Les fonctions et méthodes ne doivent pas dépasser 50 lignes, sinon tu dois découper.

Ce dont tu parles, c'est une bonne pratique, pas une obligation. Il est conseillé d'éviter d'écrire des fonctions et des méthodes de plus de 50 lignes, mais ça n'est pas une règle absolue.

En plus, tu mélanges des aspects "objet" avec du code procédural : la seule fonction doit être main(*args), protégée :

C'est un truc que j'ai trouvé dans quasiment tous les projets sur lesquels je suis intervenu. C'est pas forcément une bonne chose, mais c'est la réalité.

Tu noteras que plutôt que de mettre 20 args à mon __init__, j'utilise l'opérateur splat qui permet de passer un **kwargs, qui est le dictionnaire de tous les paramètres passée, nommés.

A utiliser avec parcimonie, sinon l'utilisateur de ton code va passer son temps à remonter dans la hierachie de classe pour découvrir la véritable signature du constructeur ou de la fonction.

C'est pratique d'écrire du code qui manipule un kwargs, c'est la plaie à maintenir et faire évoluer et à comprendre. C'est l'équivalent de l'utilisation des dictionnaires en PHP, et c'est souvent compliqué de monter en compétence sur du code qui en fait une utilisation forte. (je sais, les pythonistes vont me jeter des cailloux, mais plus de 15 ans de développement dont 10 à faire du python, ça fait voir du pays, et ça permet d'avoir un regard critique sur les "bonnes" pratiques)

Je réagis un peu fort, peut-être, mais els introductions du type "Je fais du python au quotidien... et là je suis séché : je n'ai jamais rien lu de si moche !" ça fait un peu trop le mec qui s'y connait et qui prend le débutant pour un nase.

Tout le monde a été débutant à un moment ou à un autre ; y'a pas besoin de prendre les débutants de haut pour leur expliquer des trucs. Ca me fait penser aux développeurs qui font passer des entretiens et qui trouvent que les candidats sont nuls parce qu'ils n'ont pas réussi à répondre à tous les problèmes spécifiques qui font leur quotidien. Bah oui : si le mec qui bosse ailleurs sait faire exactement tout ce que tu vois comme problème au quotidien, c'est soit qu'il est vraiment plus fort que toi (parce que lui, il ne sait pas ce que tu as en tête et il n'est pas dans ton contexte), soit que tu es nase... soit les deux.

Par rapport aux remarques de François, deux remarques complémentaires :

les variables privées commencent par un _

Il faut bien avoir en tête que les variables privées ou attributs de classe commencent par un _ par convention

Et aussi un point sur les commentaires. L'intérêt d'un commentaire n'est pas d'expliquer ce que fait le code mais pourquoi il le fait. Par exemple dans le code suivant :

 ``self.thing = kwargs.get('thing', None) # None by default`

Le commentaire est inutile : il décrit simplement le comportement de la méthode get()

Dernier point : si tu aimes coder, persévère. Tu vas écrire du code et 1 mois plus tard tu le trouveras dégueu. Ca va continuer comme ça pendant longtemps... au fur et à mesure tu vas passer de 1 mois à 2, puis 3, puis 6, puis 12... mais tu ne seras probablement jamais satisfait de ce que tu as écrit, car ton expérience change, ta maîtrise du sujet que tu essaies de résoudre va se préciser et donc la manière de concevoir ou de modéliser évolue.

Je rejoins François dans ce qu'il ne dit pas explicitement mais qui ressort de sa réponse : il faut essayer d'appliquer les bonnes pratiques. Ca rend ton code plus standard, plus propre en général, et ça permet plus facilement de travailler à plusieurs. Choisi également une approche principale : tu fais de la programmation objet ou tu préfères faire du procédural ? Formatte ton code et standardise-le, il y a pas mal d'outils pour cela : flake, pylint, black, par exemple, et pas mal de bonnes pratiques "standards" que tu peux retrouver dans les pep - dont la fameuse pep8

#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo