Since I was young, my father has encouraged me to become a writer, so a few years ago, I entertained the idea, and bought a book by Stephen King called “On Writing”. From it, I learned several aspects of good writing. One of the most memorable was to avoid adverbs ending in -ly. The reason they should be avoided is because your verbs, nouns and adjectives should describe your intentions without the use of adverbs. Adverbs are extra fluff, and when overused, are the mark of an immature writing style.
Until I read that book, I never thought about the importance of one sentence. A good novel writer ensures that his audience is not subjected to needless modifiers that serve to support poorly written sentences. Not only this, but he does it on a consistent basis, one sentence at a time, until the entire novel is written, all the while focusing on the overall plot of the book. The mark of quality in a novel is it’s ability to move the plot forward while avoiding unnecessary distractions. This hallmark is established with each and every sentence.
In the publishing world, there are checks and balances to ensure that before a novel is released, the quality of the novel matches up to certain standards. After the novelist writes the novel, he sends the manuscript to the publisher, who typically suggests one or many edits that the manuscript needs before it’s ready to be published. The novelist then edits his manuscript and repeats this process until the book is ready to publish.
Now, liken yourself to a novelist. You have a novel (your code) full of sentences (lines) that you’re tasked to write. The assumption is that you will not only focus on the purpose of the application, but will also focus on how that purpose is to be achieved, by paying attention to each and every line of code. I’ve heard it said recently that “it only takes one line to create a dependency”. This statement shows the power that one line of code can have. It can make or break your application.
So what is code quality? Quality code can only come from paying attention to each line you write. As I’m writing this blog, I’m paying attention to each and every sentence I write. I’m reviewing each one to verify they communicate my point clearly and concisely. The reason I’m doing this is because I know there are people who will read this post. They’ll analyze what I’m saying, and won’t want to waste their time while reading it. They expect to learn something from every sentence.
So why don’t we do this as much in our code? I think it’s because we believe that our code will never be read. It will only be used. This is a false assumption that needs rejecting. Every day I read the code I’ve read in order to modify it, or in order to hunt down a bug. The way the code is written is almost as important as what it does. Poorly written code takes longer to maintain. Well written code can be maintained almost effortlessly.
Each line of code should serve a purpose. Each set of lines should be reviewed as it’s being written, to ensure the most clear and concise expression of the concept is found. Each architectural construct should be reviewed for it’s flexibility and it’s contribution to the overall goal. This should happen not in a designated refactoring session, but during the moment-by-moment process of coding.
This takes patience, consistency and the ability to clearly adhere to and express the purpose.
Code quality, in my definition, is a well-assembled collection of well-expressed lines of code, none of them being taken for granted. This is a basic concept, but one that needs reinforcing from time to time. There are so many concepts to quality programming that it takes a lifetime to master them all (if indeed they can be mastered), but for a good start allow me to suggest SOLID principles and design patterns. Professional programmers will learn these techniques and use them to their advantage. Poor programmers will abuse the code and muddle it’s intentions.
Refactor in the small, and refactor consistently as you go. A good place to start might be to begin reading Sean Chambers’ current blog series entitled 31 Days of Refactoring. Refactoring as you go can help to prevent technical debt.
Learn these techniques and apply them as you go, not after the fact, and you’ll find at the end that your code can be as enjoyable to read as some of the world’s greatest authors, from Hemingway to King to Rowling.
Write code like it’s going to be read.
