How to write less comments (DRY-Principle) ?
(Clean Code Quality Seal : Red)
Table of contents
How can i write less comments witout loosing context in my app?
Do you want to see some examples?
Source code convention tools
Literature, good books and references
How can i subscribe/feed this blog ?
How can i rate this blog ?
Where do i find more clean code knowledge and gadgets?
How can i write less comments without loosing context in my app?
Hi There! In this blog i wanna show you that agility has nothing to do with "no comments". The most developers i know missunderstand the meaning of agile concepts, Xtrem-Programming and other agile concepts associating it automatically with no comments. Applications totally without comments works exactly as long as the code owner works in your company. In fact we can associate agility with LESS, reusable, concise comments. Here some ideas how to write agile comments making your code readable, understandable and reusable. Share this blog with your collegues doing know-how exchange.
How can i write readable, understandable comments?well to do that, we must understand how to comment in the different situations we have in our code. For this reason i have established some comment rules for myself:
How can i write readable, understandable comments?well to do that, we must understand how to comment in the different situations we have in our code. For this reason i have established some comment rules for myself:
- private variables should comment itself (here you don't need more comments then that)
- private methods should comment itself (here you don't need more comments then that)
- public static variables should be commented inline over annotations (if possible and reusable)
- static methods should be commented inline over annotations (if possible and reusable)
- public methods should be commented over interfaces
- private classes should comment itself (here you don't need more comments then that)
- public static classes should be commented inline over annotations (if possible and reusable)
- public classes should be commented inline over annotations (if possible and reusable)
- Interfaces should be commented normaly
- private constructors should be commented over annotations (@singletonPattern...)
- public constructors should be commented over annotations (if possible and reusable)
Do you want to see some examples?
See "how to write good, reusable comments" - Link
