You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my experience the single most valuable docstring are ones on the structs, as there are least amount of them, yet they are the very core of every project. Then the docs on the methods, and the rest is great to have but not as important, especially for an application code.
Unfortunately there's no good way to take it into account when trying to enforce better docstring coverage, ATM. If I add #[warn(missing_docs)] trying to up our documentation game in a large project it generates tons of warning, lots of them not that important to immediately fix.
For these two reasons:
not all docstring types as equally valuable
being able to more gradually enforce better docs coverage
I'd love to have some #[warn(missing_struct_docs)], #[warn(missing_method_docs)], etc.
What it does
In my experience the single most valuable docstring are ones on the
structs
, as there are least amount of them, yet they are the very core of every project. Then the docs on the methods, and the rest is great to have but not as important, especially for an application code.Unfortunately there's no good way to take it into account when trying to enforce better docstring coverage, ATM. If I add
#[warn(missing_docs)]
trying to up our documentation game in a large project it generates tons of warning, lots of them not that important to immediately fix.For these two reasons:
I'd love to have some
#[warn(missing_struct_docs)]
,#[warn(missing_method_docs)]
, etc.I originally posted this idea on https://internals.rust-lang.org/t/more-granular-missing-docs/19953 , but was suggested that making this a clippy lint (first), might be a good approach.
Advantage
No response
Drawbacks
No response
Example
na
The text was updated successfully, but these errors were encountered: