I really love the idea of “Clean Code”. Keeping our classes and methods short, naming things well, and making sure our comments are actually helpful all makes a whole lot of sense. What’s even better about it is that its not a particularly complicated idea. It could be explained in a couple of hours, and even the most junior of developers shouldn’t have a problem grasping the main principles. It also doesn’t usually take too long to clean up dirty code. Rename some variables, extract some short methods out of long methods, and review the comments. The only slightly tricky bit is extracting a helper class out of a class that has grown too big.
So why don’t I write clean code all the time? Why isn’t all the code I’ve written since I heard about clean code a shining example of code cleanliness?
Well the brutal truth is, when I’m writing code, I’m not thinking about cleanness. I’m completely focused on what can I do to get the feature implemented. So at the point that I’m “done” in the sense of having working code and passing tests, my code is probably in a mess.
The trouble is, there is a huge temptation to skip the “cleaning” phase. After all, there’s always plenty of new development tasks waiting that I’m itching to get started on. But if we really believe that we spend ten times the amount of time reading code compared to writing it, then spending fifteen minutes cleaning our code before we move on will actually make us go much faster in the long-run.
Clean code is a habit you need to force yourself to learn. Clean before moving on to the next task. When the test goes green its time to clean. Clean before commit. If it’s not clean, it’s not complete.
PS: be sure to check out Corey House’s excellent Pluralsight course on Clean Code.