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.
Definition
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
if(referential.getClassification().getCategories().contains(rule.getInformations().getCategory()) |
|
|
Final List<Category> classifCategories = referential.getClassification().getCategories();
Final Category ruleCateg = rule.getInformations().getCategory());
if(classifCategories.contains(ruleCateg)) |
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?
Posted by
Armel GOURIOU (See other posts)
Armel Gouriou has a Master's degree in computer science and is a huge Java addict. He originally worked for Tocea's R&D team where he took part in the development of Tocea's audit and refactoring softwares. He is now a member of the professional services team where his mission is to provide companies with solutions to tackle their technical debt.
Tags:
application,
Comment,
debt,
maintainability,
number
Comments are closed.
Comment rate in applications: the higher the better?
Posted by Armel GOURIOU in Metric Meanings on June 29, 2012 with 2 Comments
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.
Definition
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 :
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.
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.
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:
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?
Posted by
Armel Gouriou has a Master's degree in computer science and is a huge Java addict. He originally worked for Tocea's R&D team where he took part in the development of Tocea's audit and refactoring softwares. He is now a member of the professional services team where his mission is to provide companies with solutions to tackle their technical debt.
2 Comments
http://tocea.comStephane on August 29, 2012
Good idea to separate API/non-API documentation. Things I document in APIs are pre/post-conditions. For post-conditions, my JavaDoc documents what are the complex structures that are returned (e.g., if I return tuples). Also, if parameters are modified during an invocation, this is very important. This helps clarify what is the contract.
For non API documentation, as you state, the goal is to help understand the program. If the code does this, then fantastic. One thing I document in non API documentation is a summary of why there is weird/complicated code. If you are doing a topological sort before processing some data, indicating why you are doing the TP sort is more useful than how it is implemented.
For example:
// Some elements depend on others being processed first. Topological order will
// make sure an element is processed AFTER its dependencies
data := tp_sort(data)
foreach d in data
…
http://tocea.comArmel GOURIOU on August 30, 2012
Thanks for your comment Stephane.
I like your point regarding modification of parameters. This can be totally confusing for an API’s user if this is not clearly commented.
Also, as you say for complicated code, commenting the WHY is often more useful than commenting the HOW. I think this makes comments less prone to deprecation: the implementation of an algorithm might evolve over time, opening opportunities for outdated comments, while the goal of the algorithm won’t change.
Comments are closed.