“Design Smart, Code Stupid” is just another way of saying “Don’t be clever” at the code level. Remember that as soon as you write some code, you are now its primary maintainer. If the code base is a hobby project, you may be the only maintainer, so you owe it to yourself to make your code easy to read. If its not a hobby project, it becomes even more important (if only to save face!); the last thing you want is other developer’s looking at your code and thinking “what does this line do?!” Instead, another developer should look at your code and think, “this makes total sense, anybody could write this!” A little self-test is to revisit your code a week or two after you wrote it. If it confuses you and produces a lot of “wtf?” then you need to simplify it.

Do you really need to use a ternary operator? Is it honestly easier to do a bit mask and a bit shift in the same statement? You may want to reconsider that nested a.getB().getC().getD().doSomething() you have going there.

So that’s the “code stupid” part… kinda starting backwards here.

So every line should be obvious, but each one should also go toward solving a problem (why else is it there anyhow). As you take the view higher and higher through the system, it should continue to make just as much sense. Each method should be well-named so that a person does not even need to look at it to know what the purpose is: the calling of a method should be as obvious as a built-in language construct. At the class or module level, it should be obvious what role it serves in the big picture. Multiple modules and classes should be “packaged” together as a cohesive unit that solves some problem.

Essentially, at whatever level a person looks, it should be obvious what what the system is doing, and why it is being done in the way chosen (even if there are alternative methods).

And you know what, another developer will look at the design and think “Man, that’s smart!” Because it is not easy to do for any non-trivial problem.

Because you know what, if you don’t have a good view of the big picture design of your system, then neither will anybody else. Instead, you will have a hodge podge of classes and methods that sort of work together. You need to know what it is you are building before you build it. Always think about the Use Cases!

I have no idea if Steve McCcconell uses the phrase in “Code Complete.” I would not be surprised, as entire book is really devoted to the idea of building a system that makes sense at every level. So I know that I am havingaa completely un-original thought, and I’ll freely admit it. I have no doubt read it so many times that its worked its way into me into some sort of meme. Nonetheless, I just thought I’d talk about it for a bit. I try to live it and know that I screw it up all the time.

Update: Fixed the sentence on Code Complete, realized that I had left out like 4 words 😉