Bonsoir,
je viens de découvrir Pylint (http://www.logilab.org/857) qui analyse du code Python et créer un rapport sur sa qualité. J'apprécie vraiment la démarche mais j'aimerais savoir ce que vous pensez des règles suivies par ce programme. Quelques exemples :
 
* lignes limitées à 80 caractères;
* nécessité de commencer un fichier par un docstring ("""/""" ) et non par des commentaires (# / # / #)
* nécessité de mettre des espaces avant/après les opérateurs (a == b)
* une virgule en fin de ligne doit être suivie d'un espace (? pas sûr d'avoir compris cette règle)
* les arguments doivent correspondre à une regex
* complexité du code limitée
 
Je comprends bien l'intérêt de ce formatage; j'aimerais juste être motivé pour réécrire mon code en suivant ces règles. Qu'en pensez-vous ?

Les lignes trop longues sont pénibles car il faut utiliser la barre de scrolling horizontale pour les voir.
De nos jours avec nos écrans plus larges, on pourrait augmenter un peu cette limite de 80.

Pour les espaces, je trouve que le mieux est de suivre les règles qui existent déjà depuis des siècles dans l'imprimerie.
C'est-à dire, de mettre un espace après une virgule, et non pas avant, ou de ne pas en mettre du tout ;
de mettre des espaces pour séparer les noms, ce qui est surtout utile dans les formules, parce que par exemple, si on écrit a-b au lieu de a - b, on peut croit que l'on a tiret b au lieu de a moins b. Avoir des espaces permet de bien voir les opérateurs (- + *  = ...) et donc la lecture du code en devient plus aisée.

Un code complexe sera difficile à lire. Parfois, il suffit d'écrire deux lignes au lieu d'une pour que ce soit beaucoup plus clair.
Si le code est complexe, le programmeur va peut-être ajouter des lignes de commentaires pour expliquer un peu son code. Mais ensuite, il pourra vouloir changer un peu son code, en oubliant de changer le commentaire, et là ça devient une horreur à relire (c'est du vécu pour moi).
 
Les profs d'informatique, et les informaticiens débutants, n'ont pas le temps de s'intéresser au formatage. Mais pourtant, quand on commence à avoir de l'expérience, on s'aperçoit que ça compte. Donc, bravo à vous, qui semblez encore jeune, mais qui avez, malgré tout, senti qu'une bonne présentation n'est pas que du luxe.

> billgatesanonym : merci de m'avoir répondu.
 
Je relance ma question : dans le monde professionnel, de telles règles sont-elles fréquemment exigées ? Quel bénéfice les programmeurs en retirent-ils ?
 
Merci à ceux qui m'ont lu !

Salut.
En ce qui me concerne voici les remarques que j'aurai à propos de ces règles:
- Les lignes trop longues deviennent vite cryptiques.. Si tu écris dans un langage comme Ruby ou Perl typiquement, tu peux vite écrire une ligne qui fait 25 transformations différentes, ce qui rend la compréhension du code assez compliquée. Donc en effet, plus de lignes et plus courtes.
Ces histoires d'espaces avant/après les opérateurs/parenthèses, je trouve que c'est inutile. Tu fais ce que t'as envie.
 
En ce qui concerne la complexité du code, là je pense qu'il y a vraiment matière à reflechir et à décider au cas par cas. Le 1er principe que j'utilise lorsque j'écris un code c'est: Ecrire un code en tentant de le rendre optimal sans avoir des bench à l'appuis est totalement débile.
Donc la 1ère écriture du code, je favorise toujours un code lisible par rapport à un code ultra-optimisé. Une fois que la fonction est écrite, tu la bench, tu estimes combien de fois cette fonction va être exécutée (ça ne sert à RIEN de passer du temps à optimiser un fonction qui va être lancée une fois par semaine) et ensuite tu optimises en fonction.

 
Au boulot on utilise pylint en tant que hook lors du commit sur le serveur git. Dès qu'il y a une erreur détectée, le commit est refusé. Par contre pour tout ce qui est warning (genre le nombre de caractère, les espaces, ...), on laissse passer même si généralement le gars qui commit un fichier sans les espaces corrects à toute l'équipe de dev qui lui tombe dessus derrière  
 
Une des seules règles que l'on ne respsecte pas est celle des 80 caractères. On préfère les dépasser et avoir des noms de variable explicite. Les autres essaient d'être respectées au maximum.

esox_ch, darkpopot > merci pour vos témoignages ! J'en prends bonne note. Si d'autres veulent contribuer, ils sont les bienvenus. Je signalerai le sujet comme [résolu] d'ici une semaine.  
 
Merci à ceux qui m'ont lu !