Comments on: Reformater son code avec yapf

By: kontre

kontre — Mon, 13 Apr 2015 12:18:17 +0000

À part l'enthousiasme (ou le fric de google selon comment on voit les choses), si j'ai bien compris la grosse différence c'est qu'autopep8 ne corrige que ce qui est flaggué par pep8, point final.

Au contraire yapf va restyler tout le code quoi qu'il arrive, donc quel que soit le style de départ tu arrives au même résultat.

Mais c'est étonnant quand même comme d'un coup tout le monde parle de yapf !

By: Sam

Sam — Sat, 11 Apr 2015 12:44:47 +0000

Non pas que ça n’existait pas déjà, mais les tentatives précédentes n’avaient soulevé aucun enthousiasme, et donc pas beaucoup de contrib. Il a fallut, comme d’hab, qu’un concours de celui qui a la plus grosse motive tout ça à coup d’éGOs, si vous voyez ce que je veux dire. On a bien eu pip intégré à Python parce que les codeurs JS se foutaient de notre gueule avec npm installé par défaut.

By: jc

jc — Sat, 11 Apr 2015 12:34:37 +0000

Je ne sais pas si j’ai raté un truc, mais concrètement par rapport a autopep8, qu’apporte yapf?

By: Neuronyk

Neuronyk — Fri, 10 Apr 2015 06:53:31 +0000

moi, pour mon premier commentaire et en n’oubliant pas remercier ce site et ses auteurs pour la qualité de leurs articles, je plussoie le sublime-linter-pep8 évoqué plus haut !

en effet, developpeur débutant non pro, si mon code est encore loin d’etre pythonic, qu’il fonctionne encore trop souvent grace a de subtils coup de chance, et bien au moins il est pep8 (hahum) et a force de corriger via le linter visuel et bien j’ai pris l’habitude de cette convention et naturellement je l’applique. (en revanche, tj du mal a anglifier)

By: doublenain

doublenain — Thu, 09 Apr 2015 10:20:50 +0000

Un autre outil intéressant :

https://github.com/landscapeio/prospector

By: Sam

Sam — Thu, 09 Apr 2015 09:30:43 +0000

@toub: l'immense majorité des codes qui sont utilisés. Il y a plein de petits projets qui ne le sont pas, mais dès que tu as une lib qui devient un peu utilisée, elle l'est. Si elle ne l'est pas, les premiers contributeurs vont généralement la reformater pour permettre de mieux travailler par la suite. Ca fait vraiment partie de l'adn de la communauté Python.

Mais la communauté est assez saine là dessus : pas de comportement formatnazi. Si quelques règles sont oubliées, c'est pas la mer à boire. L'important c'est de pouvoir scanner facilement le code de ses yeux leur d'une lecture rapide.

By: Poisson

Poisson — Thu, 09 Apr 2015 09:24:07 +0000

D’autant plus que la PEP8 est une convention et que ton script python ne va pas s’arrêter de fonctionner parce que tu ne le respectes pas. C’est une référence qui a le mérite d’exister qui impose de bonnes pratiques. Je tombe régulièrement (je suis dans un contexte de calcul scientifique) sur des codes très mal formatés de vieux de la vieille ayant chacuns leurs habitudes. Résultat des courses, il faut parfois tout reprendre/tout recoder pour améliorer les routines.

By: toub

toub — Thu, 09 Apr 2015 09:23:56 +0000

@sam

je me rends pas compte à quel point c’est utilisé pep8. Tu dis que les gens utilisent 80% de pep8, mais TOUS les projets sont en pep8 ?

Si c’est le cas pas de doute je vais bien devoir m’y coller – même si ça me fait quand même un peu chier… ;-)

By: toub

toub — Thu, 09 Apr 2015 09:21:08 +0000

@Knutknut

je me suis mal exprimé, je me fais pas mes propres coding rules, heureusement, je parlais des coding rules des projets auxquels j’ai participé, et qui ont en général cette règle là.

Sinon oui je suis bien conscient de l’intérêt d’avoir des règles de codage partagée entre les membres du projet

By: Sam

Sam — Thu, 09 Apr 2015 09:06:49 +0000

Au nom du travail d'équipe. Tous les goûts sont dans la nature, et beaucoup de style se valent. On peut passer des années à en discuter et jamais se mettre d'accord. Le PEP8 tranche et dit "ca sera pas parfait, mais au moins on fera tous la même chose".

C'est la raison pour laquelle il est si facile d'arriver dans un nouveau projet en Python. La plupart des gens respectent 80% du PEP8, et donc tu peux très vite lire et modifier un code étranger. En C++, tu va avoir des conventions différentes partout, et dès que tu vas arriver dans un nouveau projet, ta productivité va baisser aussi à cause de ça. Le pire, c'est quand tu travaille sur 2, 3 projets avec des conventions différentes. A chaque fois que tu switch, ton contexte mentale doit changer, et c'est tuant.

C'est donc un compromis qui fait passer l'individu après la collectivité.