Python code documentation
Docstrings
Docstrings are structured comments, associated with segments (rather than lines) of code which can be used to generate documentation for users (and yourself!) of your project. They allow you to provide documentation to a segment (function, class, method) that is relevant for the user. Docstrings are placed in triple quotes """ and enable automated generation of API documentation.
Two docstring styles are commonly used for their readability:
def func(arg1, arg2):
"""Summary line.
Extended description of function.
Parameters
----------
arg1 : int
Description of arg1
arg2 : str
Description of arg2
Returns
-------
bool
Description of return value
"""
return True⮕ Check out the NumPy style guide or a full example.
def func(arg1, arg2):
"""Summary line.
Extended description of function.
Args:
arg1 (int): Description of arg1
arg2 (str): Description of arg2
Returns:
bool: Description of return value
"""
return True⮕ Check out the Google style guide or a full example.
Docstring formatting
Python’s PEP 257 provides guidelines on how to effectively write docstrings to ensure they are clear, concise, and useful. Some pointers:
- The summary sentence of the docstring should appear on the same line as the opening triple quotes.
- The closing triple quotes should be placed on a separate line, except for one-line docstrings.
- Docstrings for methods and functions should not have blank lines before or after them.
- Docstrings for classes should immediately follow the class definition without any preceding blank lines. However, a single blank line should follow the docstring, separating it from subsequent code such as class variables or the init method.
- The content of a docstring must align with the indentation level of the code it documents.
Docstring contents
Formatting conventions are important for clarity and readability across different APIs or libraries. Here we adhere to the numpydoc convention.
Summaries
Docstrings should start with a one-sentence summary and if additional clarification is needed, you could add an extended summary. For functions and methods, use imperative voice, framing its summary as a command or instruction that the user can execute through the API. For classes, the summary should clearly describe what the class represents or its primary responsibility.
Parameters and arguments
The Parameters section lists the input parameters of a class, function, or method. It should include the parameter name, type, and a brief description of what the parameter represents. Parameters are listed in the same order as they appear in the function definition.
Returns and Yields
Returns is an explanation about the returned values and their types, following the same format as Parameters. This is applicable to functions and methods. Use Yields for generators.
Raises
For classes, methods, and functions the Raises section is used to describe exceptions that are explicitly raised.