Error Codes

Missing Docstrings
D100	Missing docstring in public module.
D101	Missing docstring in public class.
D102	Missing docstring in public method.
D103	Missing docstring in public function.
D104	Missing docstring in public package.
D105	Missing docstring in magic method.
D106	Missing docstring in public nested class.
D107	Missing docstring in __init__ method.
Whitespace Issues
D200	One-line docstring should fit on one line with quotes (found {} lines).
D201	No blank lines allowed before function/method docstring (found {}).
D202	No blank lines allowed after function/method docstring (found {}).
D203	Class docstrings should have 1 blank line before them (found {}).
D204	1 blank line required after class docstring (found {}).
D205	1 blank line required between summary line and description (found {}).
D206	Docstring should be indented with spaces, not tabs.
D207	Docstring is under-indented.
D208	Docstring is over-indented.
D209	Multi-line docstring closing quotes should be on a separate line.
D210	No whitespaces surrounding the docstring text are allowed.
D211	No blank lines allowed before class docstring (found {}).
D212	Multi-line docstring summary should start at the first line.
D213	Multi-line docstring summary should start at the second line.
D214	Section {!r} is over-indented.
D215	Section underline is over-indented in section {!r}.
Quotes Issues
D300	Use “””triple double quotes””” (found {}-quotes).
D301	Use r””” if any backslashes are present in a docstring.
Docstring Content Issues
D400	First line should end with a period (not {!r}).
D401	First line should be in imperative mood{}.
D402	First line should not be the function’s or method’s “signature”.
D403	First word of the first line should be properly capitalized ({!r}, not {!r}).
D404	First word of the docstring should not be This.
D405	Section name should be properly capitalized ({!r}, not {!r}).
D406	Section name should end with a newline ({!r}, not {!r}).
D407	Missing dashed underline after section {!r}.
D408	Section underline should be in the line following the section’s name {!r}.
D409	Section underline should match the length of its name {!r}.
D410	Missing blank line after section {!r}.
D411	Missing blank line before section {!r}.
D412	No blank lines allowed between section header {!r} and its content.
D413	Missing blank line after last section {!r}.
D414	Section {!r} has no content.
D415	First line should end with a period, question mark, or exclamation point (not {!r}).
D416	Section name should end with a colon ({!r}, not {!r}).
D417	Missing argument description{} for {}.
D418	Functions/methods decorated with @overload shouldn’t contain a docstring.
D419	Docstring is empty.
Others

Conventions

Not all error codes are checked for by default. There are three conventions that may be used by lintel: default, numpy and google.

The default convention supports parts of PEP257) and is used by default.

The numpy convention supports the numpydoc docstring standard.

The google convention supports the Google Python Style Guide.

These conventions may be specified using --convention=<name> when running lintel from the command line or by specifying the convention in a configuration file.

Two more conventions can be used: all and none. They check for all or no errors and can be used to quickly create a custom convention by adding or ignoring specific checks.

Publicity

The D1xx group of errors deals with missing docstring in public constructs: modules, classes, methods, etc. It is important to note how publicity is determined and what its effects are.

How publicity is determined

Publicity for all constructs is determined as follows: a construct is considered public if -

Its immediate parent is public and
Its name does not start with a single or double underscore.
1. Note, names that start and end with a double underscore are public (e.g. __init__.py).

A construct’s immediate parent is the construct that contains it. For example, a method’s parent is a class object. A class’ parent is usually a module, but might also be a function, method, etc. A module can either have no parent, or it can have a parent that is a package.

In order for a construct to be considered public, its immediate parent must also be public. Since this definition is recursive, it means that all of its parents need to be public. The corollary is that if a construct is considered private, then all of its descendants are also considered private. For example, a class called _Foo is considered private. A method bar in _Foo is also considered private since its parent is a private class, even though its name does not begin with a single underscore.

Note, a module’s parent is recursively checked upward until we reach a directory in sys.path to avoid considering the complete filepath of a module. For example, consider the module /_foo/bar/baz.py. If PYTHONPATH is set to /, then baz.py is private. If PYTHONPATH is set to /_foo/, then baz.py is public.

Modules are parsed to look if __all__ is defined. If so, only those top level constructs are considered public. The parser looks for __all__ defined as a literal list or tuple. As the parser doesn’t execute the module, any mutation of __all__ will not be considered.

How publicity affects error reports

The immediate effect of a construct being determined as private is that no D1xx errors will be reported for it (or its children, as the previous section explains). A private method, for instance, will not generate a D102 error, even if it has no docstring.

However, it is important to note that while docstring are optional for private construct, they are still required to adhere to your style guide. So if a private module _foo.py does not have a docstring, it will not generate a D100 error, but if it does have a docstring, that docstring might generate other errors.