Error Codes¶
Grouping¶
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__ |
Whitespace Issues | |
D200 | One-line docstring should fit on one line with quotes |
D201 | No blank lines allowed before function docstring |
D202 | No blank lines allowed after function docstring |
D203 | 1 blank line required before class docstring |
D204 | 1 blank line required after class docstring |
D205 | 1 blank line required between summary line and description |
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 allowed surrounding docstring text |
D211 | No blank lines allowed before class docstring |
D212 | Multi-line docstring summary should start at the first line |
D213 | Multi-line docstring summary should start at the second line |
D214 | Section is over-indented |
D215 | Section underline is over-indented |
Quotes Issues | |
D300 | Use “””triple double quotes””” |
D301 | Use r””” if any backslashes in a docstring |
D302 | Deprecated: Use u””” for Unicode docstrings |
Docstring Content Issues | |
D400 | First line should end with a period |
D401 | First line should be in imperative mood |
D401 | First line should be in imperative mood; try rephrasing |
D402 | First line should not be the function’s “signature” |
D403 | First word of the first line should be properly capitalized |
D404 | First word of the docstring should not be This |
D405 | Section name should be properly capitalized |
D406 | Section name should end with a newline |
D407 | Missing dashed underline after section |
D408 | Section underline should be in the line following the section’s name |
D409 | Section underline should match the length of its name |
D410 | Missing blank line after section |
D411 | Missing blank line before section |
D412 | No blank lines allowed between a section header and its content |
D413 | Missing blank line after last section |
D414 | Section has no content |
D415 | First line should end with a period, question mark, or exclamation point |
D416 | Section name should end with a colon |
D417 | Missing argument descriptions in the docstring |
D418 | Function/ Method decorated with @overload shouldn’t contain a docstring |
D419 | Docstring is empty |
Default conventions¶
Not all error codes are checked for by default. There are three conventions
that may be used by pydocstyle: pep257
, numpy
and google
.
The pep257
convention (specified in PEP257), which is enabled by default in
pydocstyle, checks for all of the above errors except for D203, D212, D213,
D214, D215, D404, D405, D406, D407, D408, D409, D410, D411, D413, D415, D416
and D417.
The numpy
convention added in v2.0.0 supports the numpydoc docstring standard. This checks all of the
errors except for D107, D203, D212, D213, D402, D413, D415, D416, and D417.
The google
convention added in v4.0.0 supports the Google Python Style
Guide. This checks for
all the errors except D203, D204, D213, D215, D400, D401, D404, D406, D407,
D408, D409 and D413.
These conventions may be specified using --convention=<name>
when
running pydocstyle from the command line or by specifying the
convention in a configuration file. See the Usage section
for more details.
Note
It makes no sense to check the same docstring for both numpy
and google
conventions. Therefore, if we successfully detect that a docstring is in the
numpy
style, we don’t check it for google
.
The reason numpy
style takes precedence over google
is that the
heuristics of detecting it are better, and we don’t want to enforce users to
provide external hints to pydocstyle in order to let it know which style
docstrings are written in.
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.
- Note, names that start and end with a double underscore are public (e.g.
__init__.py
).
- Note, names that start and end with a double underscore are public (e.g.
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.