Darglint is a functional docstring linter that checks whether a docstring's description matches the actual function or method implementation. It supports Google, Sphinx, and Numpy style docstrings, ensuring that parameters, returns, yields, and raises sections are consistent with the function signature and body. The project is currently in maintenance mode, with the author focusing on accepting pull requests rather than adding significant new features.
pip install darglintNo compatibility data collected yet for this library.
To quickly check a Python file with darglint, save your code to a .py file and run darglint directly from your terminal. It will output any docstring inconsistencies.
Update any `ignore` lists in your configuration files (e.g., `.darglint`, `setup.cfg`, `tox.ini`) or `noqa` comments to use the new 'DAR' prefixed error codes.
Users on Python 3.5 should upgrade to Python 3.6 or newer to use current `darglint` versions, or alternatively, pin to an older `darglint` release compatible with Python 3.5.
For large codebases, evaluate `darglint`'s performance. If too slow, consider using `pydoclint` or running `darglint` selectively on changed files (e.g., via `pre-commit`).
Ensure your configuration file is correctly named and contains the `[darglint]` section header. For example, a `.darglint` file in your project root with `[darglint]` at the top.
Adhere strictly to `darglint`'s Sphinx-style docstring requirements, ensuring fields are at the end, grouped, and correctly indented with four spaces.
Avoid using parentheses around simple types in docstring type annotations (e.g., write `str` instead of `(str)`). For complex types, ensure they follow Python's `PEP 484` without additional enclosing parentheses in the docstring type description.
Utilize `darglint` either as a command-line tool (`darglint <files>`) or by installing it alongside `flake8` in the same environment. Avoid relying on internal `darglint` modules for programmatic linting.
Add the missing parameter to the docstring's 'Args' (Google style), ':param:' (Sphinx style), or 'Parameters' (Numpy style) section, ensuring its name matches the function signature.
Add a 'Returns' (Google style), ':returns:' (Sphinx style), or 'Returns' (Numpy style) section to the docstring, describing the value returned by the function.
Either remove the undocumented exception from the docstring's 'Raises' section or ensure the function's body explicitly raises the described exception.
Review the docstring for syntax errors, incorrect indentation (e.g., DAR003), or extra newlines (e.g., DAR004), and ensure it strictly adheres to the chosen docstring style guide. Using an IDE with docstring formatting assistance can help.
No dependency data recorded yet.