Cet article est l'article du 21ème jour du Lint Advent Calendar 2016.
En principe, je pense qu'il est important de faire la même chose quel que soit le rédacteur afin de rendre le code hautement maintenable. Il y a eu diverses critiques à ce sujet, telles que "C'est une illusion" et "Ce n'est pas important", mais Pythonista, qui protège "Zen of Python", veut s'y tenir.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Style Guide
Afin d'avoir «le même code, peu importe qui l'écrit», l'équipe doit décider d'un guide de style. Python a un guide de style PEP8, donc si vous personnalisez chacun en fonction de la situation basée sur ceci C'est bon.
Vous pouvez également consulter le Google Python Style Guide.
Une fois que vous avez un guide de style, vous pouvez l'appliquer lors de votre révision de code. Cependant, lors de la révision du code, plutôt que de passer du temps sur "veuillez unifier en guillemets simples" et "veuillez organiser l'ordre des importations", nous devrions discuter de choses plus essentielles.
Naoya en a parlé sur son blog il y a quelque temps. Trivial code review --naoya's Hatena Diary
Lorsqu'une équipe peu familiarisée avec la révision de code commence la révision de code sans aucune réflexion, elle sera signalée dans différentes tailles. À première vue, il semble que divers points ont été soulignés et que les discussions sont devenues actives, mais la plupart des discussions sont déroutantes, telles que «la largeur de retrait du code est différente» ou «le retour est omis. J'ai le retour. Dans de nombreux cas, c'est juste une question aussi triviale, comme "Je préfère" ou "Dans ce cas, il est préférable de baisser les caractères". C'est une route qui doit être empruntée une fois.
Il est inutile de discuter de telles choses sans fin. Cela ne veut rien dire, mais c'est le moins qu'on puisse dire, l'améliorer n'améliore pas du tout la qualité réelle, et si vous voulez vraiment l'avoir, vous pouvez le vérifier mécaniquement avec l'outil à peluches ou quelque chose du genre. Ce n'est pas quelque chose que les humains font.
Ce que vous devez faire est "La conception n'est pas ouverte pour l'extension et doit être ouverte" ou "Cela peut conduire à un tel problème car le cas de bord n'est pas supposé" ou "J'ai regardé le test plus tard. Il est parfois difficile pour un tiers d'interpréter les spécifications requises. " Ce sont les points qui ne peuvent être soulevés qu'en lisant correctement le code, en saisissant la structure du code et en ayant à l'esprit tout le sentiment du système autre que le code qui y est écrit.
L'important ici est
C'est une division du travail. Les humains ont un temps limité, alors automatisons ce que nous pouvons faire.
Pour les outils Lint (flake8 et pylint) en Python, il est recommandé de lire les documents suivants pour approfondir votre compréhension.
Outils de refactorisation, etc.
Ici, je voudrais vous présenter ce que j'utilise habituellement dans mon travail.
Dans "Zen of Python"
Faisons bon usage de Lint pour mettre en pratique l'esprit de.
Recommended Posts