Why do you need quality control tools

Needless to say, I’m paranoid that all projects written in dynamic languages should use a tool like XXLint to expose bugs as soon as possible.

Even more, all projects need to do two things before committing:

  1. Lint check
  2. UT

Dynamic languages are interpreted and executed at the same time and lack compile time. It’s a weakness and a strength. It’s a strength and a weakness.

Common quality control tools in Python are pyTest (or others), Pylint, and Flake8 (more powerful). This article covers the last two.

How to use

If neither of these tools is mentioned, it is natural to think that given the source directory SRC, the tool should be able to check all files in SRC that meet the requirements, i.e.

flake8 $OPTIONS $src
Copy the code

In fact, that’s how these tools work. Specify a file or directory, and it checks for you.

Integration with workflow

The command line is fairly simple to use, but no one uses it (it’s still repetitive work), and few people like to read long documents, so best practices are the focus.

My personal best practice is to combine it with git pre-commit and not commit it if it’s not checked.

The ideas are as follows:

  1. Pre-commit is written using bash scripts and executed using corresponding commands
  2. Pre-commit is written using Python scripts (my personal preference is this, mainly because I don’t really love shells)

If I’m using Python scripts, I prefer to use Fabric to organize my code (Fabric is simple and small enough).

For example, a project structure might look like this:

.pylintrc
.flake8
fabfile.py
project/
tests/
docs/
Copy the code

So the contents of fabfile.py are roughly


@task
def runpylint():
    local('pylint project/')
    
@task
def runflake8():
    local('flake8 project/') @task def runPyTest (): pass@task def runFabFile (): execute(runPyLint) execute(runFlake8) execute(runPyTest) fab runfabfileCopy the code

Git /hooks/pre-commit

#! /usr/bin/env bash
function _runfab() {
    fab runfabfile
    
    if [[ "$?" == 0 ]]; then
        return 0
    else
        return 1
    fi
}

_runfab
Copy the code

conclusion

The use of tools, of course, is not the point, the principle is. A few principles that I think are important are:

  1. Be strict with everything. Such as PylintCLevel errors should also be avoided (some checks are redundant and can be disabled, but as few as possible should be disabled).
  2. Not only with pre-commit, but also with CI tools, leaving no dead ends.