This article is the 21st day article of Lint Advent Calendar 2016.
As a premise, I think it is important to do the same regardless of who writes it in order to make the code highly maintainable. There have been various criticisms about this, such as "It's an illusion" and "It's not important", but Pythonista, which protects "Zen of Python", wants to stick to it.
>>> 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
In order to have the same code no matter who writes it, the team needs to decide on a Style Guide. Python has a Style Guide PEP8, so if you customize each one according to the situation based on this It's good.
You can also refer to Google Python Style Guide.
Once you have a Style Guide, you can apply it during a code review. However, in code reviews, rather than spending time on "unify to single quotes" and "arrange the order of imports", we should have a much more essential discussion.
Naoya talked about this on his blog a while ago. Trivial Code Review-Naoya's Hatena Diary
When a team unfamiliar with code review starts code review without any thought, it will be pointed out in various sizes. At first glance, it seems that various points have been pointed out and discussions have become active, but most of the discussions are confusing, such as "the indentation width of the code is different" or "return is omitted. I have return. In many cases, there are only trivial things such as "I like it better" or "In that case, it looks better to indent". It is a road that must be taken once.
There is no point in discussing such things endlessly. It doesn't mean anything, to say the least, improving it doesn't really improve the quality at all, and if you really want to get it, you can mechanically check it with a lint tool or something. It is not something that humans do.
What you have to do is "The design is not open for the extension and should be opened" or "This may lead to such a problem because the edge case is not assumed" or "I looked back at the test at a later date. Sometimes it is difficult for a third party to interpret the required specifications. " These are the points that can only be made by reading the code properly, grasping the structure of the code, and having the whole feeling of the system other than the code written there in mind.
The important thing here is
It is a division of labor. Humans have a finite amount of time, so let's automate what we can do.
For the Lint tools (flake8 and pylint) in Python, it is recommended to read the following materials to deepen your understanding.
Refactoring tools and so on
Here, I would like to introduce what I usually use in my work.
In "Zen of Python"
Let's make good use of Lint to put into practice the spirit of.
Recommended Posts