Last updated on August 18, 2020
There is a code smell I named WALOC – Write A Lot Of Code.
When you see a big method, with lots of unusual conditional statements (ifs, switches, etc.), and lots of hard-coded assignments, you may be seeing an instance of this.
This usually happens when a programmer is trying to deal with a complex problem (lots of variability and many possible ways of handling them), or when a programmer is trying to track down unusual bugs that only happen with certain inputs.
When WALOC happens while trying to fix a bug, you often see doing things that really don’t make sense – like:
if((inputValue == 7.43) && (User.Name = "Joe"))
{
inputValue = 7.44;
}
Or, you may see an “if” surrounding a bunch of code, while the “else” contains almost exactly the same code – except for a bit of hard-coded “fixes” or commented-out lines.
This is usually a sign of a junior programmer, trying to fix a bug. They don’t get to the root problem, and instead write a lot of code to cover up the symptoms of the problem.
The other situation, the one I started to run into today, is when a set of rules for the program starts out small, and gets bigger (and more complex).
For my multi-database SQL query generator, I added in handling of inner joins and the ability to “group by” this morning. Then I started to add in handling for “having” conditions. The code wasn’t especially complex, but getting the interfaces of my fluent interface to restrict and allow the right methods, at the right times, was starting to get messy.
So I took a break from writing the code and started drawing out what I wanted to accomplish. That made it much clearer.
Someone once said that if the code is messy, it means that the programmer either doesn’t understand the language or doesn’t understand the problem.
I agree with that.
Today’s improvement: When a problem gets complex, don’t just keep writing code. Build a visual reference, to ensure you’re covering all options.