NVIDIA / NVIDIA/cuopt

[QST] How does coderabbit measure doc coverage?

Open
#1,425 4 comments 0 reactions 1 assignee View on GitHub

@Kh4ster is already working on this.

Since Jun 11, 2026.

awaiting response question
Dominant language
Cuda
Stars
1k
Forks
233
Avg merge
4d 4h
Merged PRs (30d)
95

Description

What is your question?

The CodeRabbit docstring coverage evaluation is unclear and appears inconsistent with the repository’s documentation requirements.

In this PR/commit:

https://github.com/NVIDIA/cuopt/pull/1405/commits/2a98a4f2f04c966fa6818ac6d8de5d86f819bffe

CodeRabbit reports:

Docstring coverage is 71.43% which is insufficient. The required threshold is 80.00%.

Since 71.43% = 5/7, it appears CodeRabbit is counting 7 modified symbols. However, the modified methods appear to already have documentation where required, and the report does not list which 2 symbols are considered undocumented.

I then tried adding inline documentation in this commit:

https://github.com/NVIDIA/cuopt/pull/1405/commits/4dc4a444cd89ca41ee52096574700cd263c7d154

Unexpectedly, the reported coverage became:

Docstring coverage is 62.50% which is insufficient. The required threshold is 80.00%.

That looks like 5/8, meaning the change increased the denominator but did not increase the documented-symbol count.

Could you please explain the docstring coverage rules used by CodeRabbit, specifically:

  1. Which symbols are counted in the numerator and denominator?
  2. Are C++ structs/classes counted, or only functions/methods?
  3. Are changed existing symbols counted even if the declaration itself was not modified?
  4. What comment formats are recognized for C++ documentation? For example, are ///, //! \brief, and /** ... */ all accepted?
  5. Is there a way to make CodeRabbit list the exact symbols considered undocumented?

Without this information, it is difficult to act on the coverage warning without unnecessary trial-and-error commits.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.