revive
revive copied to clipboard
mgechev
Add a comment length checking in `rule.exported`
Is your feature request related to a problem? Please describe. Hello. We would like to have a comment length checking for exported types and methods on our project.
Describe the solution you'd like Add an argument for the rule for setting a minimum required comment length
Describe alternatives you've considered I seached for this functionality in other linters but didn't find anything
This sounds like an interesting proposal. Do you think you can provide a PR for that @NikitaSkrynnik ? I'd happily review it.
@NikitaSkrynnik, side note on the rule proposal. IMO, enforcing comment min length will not help at all in comment quality. For example, I'm currently working on a code base where a "at least 25% of lines should be comments" rule is enforced and, as you might guess, developers found the way to respect the rule without bothering on the actual quality of the comment. The result of enforcing this rule is: unhappy devs (they expend time tricking the rule) and still poor comments (even worst than before)
The quality of a comment is intrinsically related with its semantic, and because comments are written in natural languages (English), it is near to impossible to measure their quality with static methods/metrics.
@chavacava thanks! After some thoughts I agree. Could you recommend any other ways to check the quality of comments?
@NikitaSkrynnik The problem of checking comment quality is still unresolved; mainly because the more fundamental question "What is a high quality comment" is still unanswered. The paper A decade of code comment quality assessment: A systematic literature review provides a good overview of where the research is on the subject.
In languages like Java or C++ where standard "markup" languages for comments are available (like Javadoc). The tooling might enforce things like "every parameter must be documented" or "potential exceptions must be documented"... anyway the quality of the actual comments is out of the reach of the analysis.
As an example of the diversity of opinions about code comments I can mention projects where comments are forbidden (with checks in the CI rejecting PR with comments). The rationale is: if you need comments to make your code clear, then it means your code is not clear enough.