Over a million developers have joined DZone.

Comment Rate in Applications: The Higher the Better?

DZone's Guide to

Comment Rate in Applications: The Higher the Better?

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

In various audit and quality tools you can find the metric “Comment rate”. What does it mean? How is it related to the application’s quality? How does it impact your technical debt? I am going to try to give you insights on this metric.


For a given application, the comment rate is the percentage of lines that are comments. With N being the number of lines of code and NC the number of lines of comments it is defined as :

Comment rate = NC / ( NC + N ) * 100

This metric must be considered with care, since a large amount of comments is not the guarantee of good comment quality. However, it gives a hint on the maintainability of the application and there are very few applications that have good reasons to be below 25%. On the opposite an application with a comment rate above 40% probably contains a great number of irrelevant or useless comments. Once again, those are not magic numbers, but they come from several hundreds of performed audits. More important than those numbers, I would like to give you hints on what is and what is not a good comment.

What you should comment

First of all, any public API and all its methods should be commented (getters and setters are the only acceptable exceptions). This is the strict minimum for any application since those comments are meant for the user of your API. Obviously it should not have to rely only on a method’s name to understand its behavior and its parameters. Furthermore most of current IDE are able to automatically generate comments, leaving you only the task to add relevant information.

Another good kind of comment is to explain something which cannot be determined just from the code. For example you may want to declare a synchronized collection in a place of the code where it is needed, but not obvious.

//Synchronized map needed: used by several producer threads latter on
Map library = new HashTable();

This is an example of good comment: the developer motivates an implementation choice or the use of a particular algorithm required by the situation.


The pitfalls of comments

A good comment rate is not enough to ensure a good maintainability of your application! I once audited an application with a very good comment rate, something above 50%. All methods where documented, each action was commented, every parameter was described. And all business code was in three classes of 3000 to 7000 lines of code… Thoroughly commenting your code will not make it automatically easy to maintain! Moreover, an overload of comments introduces noise and hides the really useful ones.

Before commenting a line of code there are at least two questions you should ask yourself. Can I express the meaning of this only with code? Check out the following example. In the original version the line is quite long and the author felt the need to comment it. In the refactored version, intermediate operations and adequate naming make the code self-explanatory.

//checks if classification of the referential contains the category of this rule


Final List<Category> classifCategories = referential.getClassification().getCategories();
Final Category ruleCateg = rule.getInformations().getCategory());


Do I comment it because it is too complicated? If yes, then try to simplify your code! Good commenting is not a valid excuse to write hard to understand, over complicated code. This is well expressed by Kernighan and Plaugher:

Don’t comment bad code—rewrite it.


Of course there are many more kinds of correct and bad comments. I will not make an exhaustive list here, which is quite impossible by the way! An important thing to remember about comments is that a good usage of them will improve your code quality. However, irrelevant or abusive usage will increase your technical debt. I hope this article gave you insight on comments in applications and that you will have a thought for it the next time you will be coding.

Now tell me, what is your politic regarding comments? Do you follow specific rules when commenting?

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}