"Clean Code" - Crafting on Principles

I’ve been reading "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert Martin. This is no ordinary book on writing better software. It’s not just a rehash of “Code Complete” or "The Pragmatic Programmer." Those are both fine books, but "Clean Code" is different. So, please don’t think that if you’ve read one, you’ve read them all. In Clean Code, Martin doesn't just name the best practices we should all be following. He explains the reasoning behind each one and gives names to the concepts. Just as the idea of software design patterns revolutionized the way we think and talk about software architecture, Martin's exploration of day-to-day coding habits gives us a smarter way to think and talk about that.

Case in point: Clean Code kicks off with the practice of giving your objects meaningful names. One aspect of this is that good names do not require anyone who might read your code in the future to have to perform any "mental mappings." Here's an example of this that I came across just the other day. var ld = new LoginData();

Look carefully, that’s a lower-case L. At first glance, it looks like a capital I, as in "ID," as in "identifier." I don't know how long I spent confused about how a class constructor could be returning an identifier when reading through this code for first time. Maybe ten or fifteen seconds? Time in which I was completely distracted from understanding the rest of the code, having pushed that problem onto the stack, as it were, in order to first solve this mini-problem. Even without the I vs. L confusion, using an abbreviated variable name meant that whenever I came across it, I had to keep reminding myself that it stood for an instance of LoginData. That may not seem like a big deal, but we humans only have so much stack space before we run out of short-term memory. When a program is full of one- and two-letter variable names that must be continually translated mentally, it leaves no room for thinking about the actual problem that the program is trying to solve.

All of this could have been avoided if the name was spelled out to begin with, so I changed it (using the automated rename refactoring tool in my IDE): var loginData = new LoginData();

"One difference between a smart programmer and a professional programmer is that the professional programmer understands that clarity is king. Professionals use their powers for good and write code that others can understand." ~ Robert (Uncle Bob) Martin

Martin could have just said, "don't use abbreviations in variables names, because you'll make the reader translate it in his head every time he reads it," and that would have been terrific advice alone. But what he really gives you is a deep understanding of the key principles involved, so that you won’t need to memorize a bunch of arbitrary coding standards in order to write cleaner code. Instead, you'll be armed with a few simple, understandable principles to guide you, with clean code being the natural outcome.

Clean Code is a must-read for everyone in the software profession — from college freshmen on up to CTOs — especially anyone who finds himself out of work in this economy (or worried about the possibility). Learning to write clean code, and thus to write more valuable code, is probably the single most effective thing you can do for yourself. Programmers are expensive resources. The work we produce is costly. It's up to us to treat it with the respect it deserves, to try and make it as valuable as possible, and to maintain that value as long as possible.




Software Design