Skip to content

Rule Types

Sourcery rules are divided into three categories: Refactorings, Suggestions, and Comments, described below.

Use the navigation menu to browse the complete list of all the Built-in Refactorings, Suggestions, and Comments.


You can extend Sourcery using Custom Rules. See the following documentation for more details:


Refactorings are rules which change code structure without changing its behaviour. For example, Sourcery will recommend you Refactor this code

my_list = [i for i in range(10)]

into this code

my_list = list(range(10))

This is a Refactoring because the code's behaviour will not change, but is simpler and therefore easier to understand. Sourcery will automatically apply this Refactoring when it can. This refactoring is called inline-variable.


Suggestions are rules which change code structure, but may change its behaviour. Suggestions are used to guide best practices, but, by default, Sourcery will not automatically fix them, and you must apply the fix manually. For example, Sourcery will make a Suggestion to change

def func(hats: list = []):


def func(hats: list = None):
    if hats is None:
        hats = []

This change is a Suggestion because using mutable defaults in function definitions is likely an error, but is not applied automatically because doing so may change your code's behaviour. This suggestion is called default-mutable-arg.


Comments are rules for specific code quality issues which have no clear or conventional solution. There may be no solution for several reasons, such as because the issue is complicated, or because it may be necessary to rename variables (for which some application knowledge is necessary). For example, Sourcery will create a Comment on the following code:

list = [1, 1, 2, 3, 5, 8]

This is a Comment because assigning to the built-in variable list is confusing and likely to lead to bugs, but Sourcery doesn't know what to call the variable instead. This Comment is known as avoid-builtin-shadow.