If we care about our craft, then we also care about cleanliness. We take care to keep our tools and environment clean – as well as the things we create. This holds true in software development. Clean code matters.
But what is clean code?
Every software engineer will have an opinion, a personal notion of clean code. Indeed it is hard to come by clear definitions in the literature. Papers refer to clean code, without defining it; the (excellent) book Clean Code does not define the expression, but instead opens by surveying the opinions of experienced software engineers. People generally have their own ideas and preferences. That’s fair.
Here is a definition that I like: Clean code is simple code that’s easy to understand and easy to test. I like that, because it is a simple sentence that is easy to remember. It evokes an image in my mind of something that is free of noise and that is easy to reason about. If we consider program code our attempt to teach another person what a computer should do (freely paraphrasing Knuth), then this definition summarizes great qualities to help achieve just that.
Your definition is probably different and that’s okay. If you’re working on a team, your team can benefit from agreeing on one definition and everyone will go with that definition for any work delivered in the context of that team.
This helps with communication. A reviewer’s handwaving at a piece of code and exclaiming “clean up that section!” will generally be met with understanding instead of confusion.
It also opens way for reasoning about cleanliness. Although we may talk in absolutes, cleanliness is of course relative – if examined over time, a code base’s cleanliness varies, hopefully generally for the better. How you think about it, determines how you can think about measuring it. This determines the kind of story you can tell.
Start by defining it.