The importance of Lint as Pythonista thinks

Introduction

This article is the 21st day article of Lint Advent Calendar 2016.

Same code no matter who writes it

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.

Code review

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.

Lint tool

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 conclusion

In "Zen of Python"

Let's make good use of Lint to put into practice the spirit of.

Recommended Posts

The importance of Lint as Pythonista thinks
The transition of baseball as seen from the data
Specify the lighting Model of SCN Material in Pythonista
Get the variable name of the variable as a character string.
Tweet the probability of precipitation as part of the function of the bot
Output the output result of sklearn.metrics.classification_report as a CSV file
The beginning of cif2cell
the zen of Python
The story of sys.path.append ()
The road to Pythonista
Revenge of the Types: Revenge of types
Get the output value of the command (as received by xargs)
Think about the analysis environment (Part 1: Overview) * As of January 2017
Measure the importance of features with a random forest tool
Display the timetable of the Morioka bus location system in Pythonista
Set information such as length on the edge of NetworkX
Extract the value of dict or list as a string
Output the result of gradient descent method as matplotlib animation