First of all, we should speak the same language. Here we collect all the specific terms that are used in this project.


Some decision that we have made regarding our python code.

Rules can say how we do things or how we do not do things. Each rule is represented with a violation.


An application developed following official guides and compatible with flake8.


flake8 plugin.

Represents a set of rules of how we do write python code in


A class compatible with flake8 used as a plugin entry point.

This class runs all visitors that exist in our application.

Technical documentation about the checker is available.


A class compatible with flake8 used to show results to users.

Each formatter operates with none or multiple violations.


A way we change existing ast nodes.

We can add properties, fix errors, delete or replace some nodes. Some of the reasons for these actions are: developer experience, simplicity, consistency across different versions, bug-fixing.


An object that goes through set of ast, tokenize, or other nodes to find violation of our rules.

Technical documentation about the Visitors API is available.


A collection of visitors.

We use this concept to be able to pass multiple visitor classes into the checker to be run.


Stylistic or semantic error that goes against our rules.

We count each violation definition as a strict rule: how should we behave in different situations.

Each violation has its own reasoning, solution, and code examples. Some violations can be configured, some violations contains related constants.

Technical documentation about the Violations API is available.