I consider myself almost a Taliban when it comes to clean coding. You cannot refactor too much, remove too much redundancy, remove globals or stop considering better names for variables and methods. Or can you?
Coding can be divided in several ways, I think. Two of them are practical coding and artful coding. Yes, you heard right, artful coding. Coding can be art.
Most programmers have found themselves with an app or a snippet of code that’s very close to their hearts. It’s excellently structured, well dispositioned awesomely named and magically effective. Wouldn’t it be great if all code you write would be like that?
Well, yes, but there is a little thing called reality and that little thing will put obstacles in the way of artful coding. Actually, artful coding should only be indulged in artful surroundings, i.e. your workshop at home.
Is the opposite to artful coding, implicitly, practical coding? Well, no. The opposite of artful coding is bad coding (a third variant of coding best left in a dark locker in the cellar). Practical coding is all about craftsmanship. Just like a good carpenter will build you a functional, yet beautiful front porch that is easily maintained and can be made bigger if you’d like to have it bigger in the future.
Like the carpenter, a programmer should apply his or her experience as well as apply the rules of the trade. Because just like for a carpenter, there are rules of the trade for a programmer.
Whereas the artful programmer goes to the extreme to make the code beautiful and effective, the practical programmer will strive to write well-formed, maintainable, working code. That will take more time than writing bad code, but a whole lot less time than writing artful code. And the extra time taken writing practical code (over bad code) is well invested when it comes to extending a chunk of code for a new feature.
Sometimes I’ve heard the argument But that piece of code won’t change in the future. I’m sure you have heard that too when arguing for a refactoring or some modernization of a snippet of code. Another argument is We can’t do that refactoring just now, but we’ll do it later.
The second argument may have some bearing, although I think that most of the time it’s just a sign of fear of breaking some functionality. But there are circumstances where it might be true. Consider for instance that you maintain two versions of a code base and the goal is to deprecate the oldest one, but you need to maintain it for another month or half a year or so. Then, due to merging issues, it might be better to delay refactorings until the old version is obsolete and unmaintained.
The first argument, however, has no validity. There is no (or at least very little) code of active systems out there for which the argument It will never change is valid. If the code is part of an active system it will change. Sooner or later. Next month, next year or in five years. It will change!
For a practical programmer, rules of the trade should always be applied. No excuses, no exceptions. Once these rules are learned and gotten used to, they will actually save time and work, even in the short run. Yes, writing a whole, new class for that simple thing you could stick in an onclick event will take a bit more time, but the class approach will allow for unit testing, it will make the code clearer to read and it will be easier to add to the next sprint.
