Need More Scouts for the Old Code
Need More Scouts for the Old Code
Join the DZone community and get the full member experience.Join For Free
In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.
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 software with any significant code base deteriorates as 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. They fear they might miss out some impact to check, or it might take more time than it's worth because the code base is worked on by so many people. 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 clean Java code, which also take less time?
I would propose the following changes for when we encounter code while working on fixing an issue:
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 Eclipse 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.
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.
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.
When you see a collection (private/local) without using Generics, and you know the type of data it can use, use Java Generics.
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.
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.
Opinions expressed by DZone contributors are their own.