1) The Observation that About 95% of the Comments Give No Added Value
If you have a rule that JavaDoc is mandatory in the project, most of the developers will use a JavaDoc generation wizard (e.g. http://jautodoc.sourceforge.net/). These generated comments are fast and create an almost worthless content. But for static code analysis tools like PMD everything looks fine.
Most of the existing JavaDoc descriptions explain the WHAT and not the WHY. Every developer should be able to read source code and the truth is in the code. Comments are in general just needed to understand, why the developer decided to use the current solution. In some cases hints to the underlying concepts of references can be helpful, e.g. design patterns, text book chapters, standard algorithms.
2) The Use of Assert to Check Valid Parameter is More Powerful than Pure Text Descriptions
Even with 100% JavaDoc and high quality of the descriptions many developers won’t read the comments as long no obvious problems appear. For these cases the automatic check of valid input to methods with asserts and/or verify functions helps more. A good example of the use of Asserts is the Spring Framework. An exception during development or testing helps more than a never read comment.
3) Readability of Source Code Getting Worse
Maybe not the most crucial drawback of extensive JavaDoc is the poor readability. The screen space is limited. This can also be a source for errors, because we are humans and more code on the screen means a better overview.
4) Over the Time a Lot of Comments Getting Wrong
Lets assume you have perfect JavaDoc comments and some enhancement request, defects or refactoring happens. A lot of comments will not be correct, because nobody took time to update them. This is a really poor situation. What should the developer believe the test in the comment or the new implementation? No documentation is better than an inconsistent or outdated documentation.
5) Refactoring will be Slower
Refactoring is – in most of the cases – a fast and easy job with the modern development tool support. Updating the JavaDoc is still a manual process which needs a lot of time. This leads to the situation that needed refactoring won’t be done because JavaDoc.
Recommendations There is more than just back and white. In some cases JavaDoc makes really sense and creates value for the maintenance team. Discus within your team when to use JavaDoc. I promise to do this in the future.
Reference: Top 5 Reasons for Not Using JavaDoc in the Next Project from our JCG partner Markus Sprunck at the Software Engineering Candies blog.
Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code
Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!
To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.