Zero 3
Clarity of code is a signal-to-noise ratio. We need our code to be as concisely meaningful as possible (not as cramped and crowded as possible, and not unnecessarily spread out over many pages). Whatever size provides the most accurate and quickest reading for trouble-shooting and enhancement is the best size.
On one of my past projects, we found ourselves able to remove a lot of dead code and as we added new features we were also able to simplify a lot of existing code. This is a very good thing, since code is a liability and functionality is an asset (I’ll elaborate more on that at a later date).
However, my manager was secretly reporting our progress in terms of lines of code/week. I was called on the carpet after some very productive weeks of producing unusually clean code. My manager’s problem was that we had been averaging over 200 lines less per week. By making the system cleaner and smaller, we were being reported as making negative progress, and were ordered to stop!
It’s just another “bad metrics” story, but it underscores an unspoken assumption that code should always grow bigger over time.
One non-zero-respecting practice is that of commenting-out code and leaving it. people have to scroll around the code, reading bits above and below, and so it is really just a speed bump for those who are trying to learn. It’s worse if the code is inside some nested level of a function than if an entire function is commented out. This is unnecessary, because a version control system holds the old code and can restore it if you really need it again (if not, consider a new VCS). Commented code is redundant with the VCS, in addition to being a nuisance.
Zero isn’t all really about comments, but about noise in general. Systems often have ‘dead code’, code which is never used but never deleted. When there are insufficient tests, one is unsure of coverage and cannot tell if a piece of code is being used or not. That means that code with zero use may have non-zero occurrences. In such systems, it can be very dangerous to remove code at all. Since the rule of zero is not respected, code accumulates.
Zero also will have us remove abstractions and interfaces when we no longer need them.
Zero tells us to remove tests when they’re no longer valuable.
Zero is a good idea.
I just located an old Jeff Atwood quote that lights up a few of the same synapses.
Trackbacks
Use the following link to trackback from your own site:
http://blog.objectmentor.com/articles/trackback/5717
Zero == Code Nirvana
re: “code is a liability and functionality is an asset”, hear, hear!. Looking forward to reading your thoughts about it.
”... if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.”
— E.W. Dijkstra, ‘On the cruelty of really teaching computing science’
>   if we wish to count lines of code, we should not regard them as “lines produced†but as “lines spent 
Be careful with that! Although you’re right, some folks could think that putting allot of statements in one line would improve the code! I think that metrics based on lines of code are useless altogether. Their only benefit is that they’re easy to measure. I’d rather measure such things as features implemented (with weight factors reflecting their complexity), test coverage and code clarity (get someone unrelated to the project to the code and measure the time she/he needs to understand what it does).