In a code review, the lower the number of WTFs/minute is as good a metric as any other. The highlighting in the quote below is mine.
Which appears facetious at first, but perhaps hints at a deeper truth: high quality code should not surprise us; we should be able to quickly and easily discern the structure and intent of the code. But doesn’t this then place software quality in the eyes of the beholder? What if the person evaluating the code isn’t familiar with the patterns used by the original developer? (Or – to be more cruel – what if they just aren’t competent enough to recognize the patterns used?) Are they not likely to harshly judge the code based on miscomprehension? (A similar suggestion to this measure is that software quality is inversely related to the amount of time required to make a modification; again the major problem with this is that it depends on the capability of the person making the change).
Too many developers are overly impressed with their own cleverness. I’ve found this more often in “classically trained” developers than self-taught developers, and I’ve found it in myself, too. Regardless the source, resist the temptation to implement cleverly… you’ll wind up writing bugs you can’t fix. Ask me how I know. Heh.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
Not a good plan. A better plan (to paraphrase Einstein) is to write the simplest code possible, but no simpler.