The last time I blogged here about cleaner code (see link for details), I wrote about how you could make your code more testable by centralizing switch statements in a factory and putting the behavior in separate objects. Today I will show you another technique to clean up your code and make it easier to test and also easier to read.
Flag arguments
Ever had a boolean parameter in a method declaration to determine if it should do one thing or another?Ever had a boolean parameter to decide what of 2 types of input you could have (radius or degrees, left or right for example)? Yes? Well so have I. Consider what these booleans mean for the reader or tester of the code. Should it be there or should I get rid of it? I know what you are about to say too: “I know what I should do”. But how often do you actually do it? Have you ever had a method that does something, and you need the same method, but just a little different step somewhere? How many times did you have conditional behavior, determined by a boolean method argument? Maybe something like this:
private String render(boolean hasCondition) {
if (hasCondition)
renderExtraStuff();
return renderNormalStuff();
}
Consider the reader of the calling code. What does it mean this parameter value true? Moving your mouse over the method call will help a little as you would see the method signature.
... render(true); ...
I’ve seen boolean flag parameters being added to do just this. Having a boolean parameter in a method call, tells me that you actually are doing 2 different things. Single responsibility wasn’t in the mind of the developer who wrote this. It would have been better to reduce the amount of parameters to zero and split this method up in 2 separate methods, one renderSuite() and one renderSingle()and let the caller decide which method would be needed. If you did this, the reader of the method would instantly know what the method did. The tests would also be a lot clearer, the tests would not have to decide with variant it would be testing. It would be clear by the method call. This refactoring would also clear the way to add more logic in the future or refactor the code of either method as needed.
private String renderSuite() {
renderExtraStuff();
return renderNormalStuff();
}
private String renderSingle() {
return renderNormalStuff();
}
But what about DRY? Don’t repeat yourself! Well, 9 out of 10 times the method is called with the same parameter value and there are only 1 or 2 places where the if statement is done. So DRY shouldn’t be an issue. But what if that is not the case, what if the if-statement is done more often? If the if-statement is done more often, then it could be a sign that it should be part of a domain class or maybe solved with polymorphism. But that is for a different blog.
Conclusion
So, if you want your code a little easier to test, remove boolean flag parameters and split your methods. Methods with less parameters are easier and they will have better names, so they will be easier to understand and extend.
If you want to read some more about this subject, here are some links:
