Documentation Coverage
Documentation coverage counts how many publicly accessible members (packages, modules, classes, methods, functions, variables, …) are documented using a Python doc-string. Based on the count of possibly documented public members and the actual number of non-empty doc-strings, a percentage of documentation coverage can be computed.
Documentation coverage is a measure of code quality, which expresses how well documented (completeness or documentation, but not necessarily quality/helpfulness of documentation) source code is. Well documented code helps to use and maintain the existing code base. It also allows for automated documentation generation.
Depending on quality standards, a coverage goal (or limit) like 90% might be defined, which considers an overall documentation coverage less then 90% as FAILED. Such a limit might be enforced by maintainers or merge rules (via CI jobs). This ensures new code introduced by merge requests (pull requests) cannot decrease the once achieved overall project’s code quality.
Quick Configuration
See the overview page on how to setup and enable the Sphinx extension in general.
Note
This is a quick and minimal configuration. See below detailed explanations.
Configure one or more Python packages for documentation coverage analysis in
conf.py
by adding a new ‘section’ defining some configuration variables. Each package is identified by an ID, which is later referred to by the report directive. Here, the ID is calledsrc
(dictionary key). Each package needs 4 configuration entries:name
Name of the Python package [1].
directory
The directory of the package to analyze.
fail_below
An integer value in range 0..100, for when a documentation coverage is considered FAILED.
levels
A dictionary of coverage limits, their description and CSS style classes.
# ============================================================================== # Sphinx-reports - DocCov # ============================================================================== report_doccov_packages = { "src": { "name": "myPackage", "directory": "../myPackage", "fail_below": 80, "levels": { 30: {"class": "report-cov-below30", "desc": "almost undocumented"}, 50: {"class": "report-cov-below50", "desc": "poorly documented"}, 80: {"class": "report-cov-below80", "desc": "roughly documented"}, 90: {"class": "report-cov-below90", "desc": "well documented"}, 100: {"class": "report-cov-below100", "desc": "excellent documented"}, "error": {"class": "report-cov-error", "desc": "internal error"}, }, } }
Add the
report:doc-coverage
directive into your Restructured Text (ReST) document... report:doc-coverage:: :packageid: src
Example Document
The following DocCoverage
document is an example on how this documentation uses the report:doc-coverage
directive. The first file consists of three parts: At first, a headline; at second second a short introduction paragraph
and at third, the report generating directive. The second file shows how to integrate that document into the navigation
bar.
DocCoverage.rst
Documentation Coverage Report
#############################
Documentation coverage generated by `docstr-coverage <https://github.com/HunterMcGushion/docstr_coverage>`__.
.. report:doc-coverage::
:packageid: src
index.rst
.. toctree::
:caption: References and Reports
:hidden:
sphinx_reports/sphinx_reports
unittests/index
coverage/index
Doc. Coverage Report <DocCoverage>
Static Type Check Report ➚ <typing/index>
.. toctree::
:caption: Appendix
:hidden:
Directives
- .. report:doc-coverage::
Add a table summarizing the documentation coverage per Python source code file (packages and/or modules).
- :packageid:
An identifier referencing a dictionary entry in the configuration variable
report_doccov_packages
defined inconf.py
.
- :legend:
Describes if and where to add a legend. Possible values:
no_legend
,top
,bottom
,both
.
Roles
There are no roles defined.
Footnotes