Hi Friends,
The Boy Scouts have a rule: “Always leave the campground cleaner than you found it.” What if we followed a similar rule in our code: “Always check a module in cleaner than when you checked it out.” No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result? – Uncle Bob
We all know how the software which has any significant code base deteriorates as the time passes, because we focus on writing new code and fix just the minimum code responsible for the issue.
If your code base is clean and you follow all the relevant best practices to make it beautiful and easy for maintenance, you should skip this post.
When most people fix the code for an issue, they fear that if they touch anything other than that, it might backfire as they either may miss out some impact to check or it might take much time than worth for themselves because the code base is worked on by so many people for so much time. And in reality, very few teams follow full TDD and where the available tests cover all possible scenarios.
But why can’t we have zero risk changes for Java towards the clean code which also take pretty less time?
I would propose following changes to do when we encounter some code to understand while working on fixing an issue:
Bad naming:
What’s in a name? If Shakespeare were born in today’s era of software, he perhaps wouldn’t have said that. Naming is that important in software maintenance as the software experts say that we should write code for humans not for machines considering the amount of time and work goes in the maintenance.
This is the most important among all suggestions. Whenever you find any variable name or private method name which doesn’t match its intention, change it to make it meaningful. In Eclispe it’s so simple to rename all its relevant references. If any variable is immutable and final, name should be in caps to drive the intention. Following is also worth considering: Naming Tips.
Outdated comments:
I’ve already talked about how bad comments can be. When you see the comment is not matching with the code which is common in any long maintenance project, remove it. If you see some code as commented, remove it.
Unused Code:
Whenever you see the unused variable or unused imports, go and remove it. It is very easy to detect in Eclipse.
Set of constants:
If you see some private set of constants, use java enums instead.
Generics:
When you see a collection (private/local) without using Generics and you know the type of data it can use, use Java Generics.
for-each loops:
If you find any tradition loop which is meant for only iterating elements and does not depend on loop index for any other work, change it to advanced for-each loop.
Bad Format:
Formatting is so easy and customizable in Eclipse, but many times we ignore this. Just use it on the files you worked on, before any check-in/commit. Ideally it should be part of automated build process.
This is not to say that we should improve only these things, but it should be good starting if each developer from the team follows the boy scout rule.
If your code is easy to understand, it is easy to maintain and improve further.
Let me know if I’ve missed something.
Happy learning,
Vishal
JavaCurious 