I have chosen this topic as another of the signs of a computer professional, according to Uncle Bob Martin. He emphasizes this negative aspect, “do not write bad code.” We all have different definitions of Bad Code.
According to Uncle Bob, any code that does not fulfill the requirements of a Unit test is bad code. Moreover, if the code extends beyond the logic of all unit tests exercising it, that would be bad code.
Others emphasize that this requirement is not sufficient, and the order of test before code is not relevant. It is just as important to have code that is designed to work well. Some would rather define an architecture in advance, and then start writing the code. Perhaps with test first, once the architecture is established.
I think that the techniques are important, but stray away from what defines good code. Good code has meets the functionality of the user’s needs without causing harm. That’s something most developers can agree on. The variations come with the process to get there. Other variations come from additional value of shared code (so we write it only once), separation of concerns, future extensibility, and other such facets setting one code set apart from another. You could say, “When software becomes too difficult to extend for new features, then it is not good code.”
What may be bad code for one system may not be bad code for another. I can see systems with less sophisticated architecture because it is intended for a narrow purpose. Many of us know that when others find this really cool system, then they want it too, and it wasn’t designed for that. So, you have two options: 1) Only use time consuming layers of separation, or 2) Allow simple systesm, with the understanding that the first time a request is made for it to go beyond the intended audience, it has to be re-written using appropriate code for the new audience. If your company can abide by the second method, then you can write simpler software, as Good Code. If your company is like many, and just says, “Make the old code work for others too.”, then don’t write it that way to start with. In that situation, it is not “Good Code.”
Most developers know when they have written bad code. Sometimes it happens when you copy something from somewhere else without understandijng how it works. You may have solved the problem. But, code you don’t understand is not Good Code.
The Take Away point is, build a solid definition of what defines good code and follow processes that produce the same.
Cheers,
Ben