A close escape, and more on inappropriate cleverness
Monday I went on the 7 hills ride.
Wednesday night, I wrote a long and detailed post about it, and hit the "Post" button.
In a fit of editorial brilliance, my blog server chose that exact moment to experience a problem, and the post vanished into the ether.
Few will quarrel that that event was a net positive for western civilization as a whole.
So, here's the short version.
HomeDownPauseUpDownUpDownUpDownUpDownUpDownPauseUpDownUpDownStrawberryShortcakeUpHome
Now, that that's out of the way, there were a few comments on the 6th deadly sin post that I'd like to comment on:
(BobHy) "Inappropriate" is relative to time (as your first story illustrates) and point-of-view ("cui bono"). Would you agree that cleverness which benefits the user who runs the code (efficiency) or the team who maintains it (maintainability) is appropriate? And if the clever bits trade off one of these against the other, who gets to decide the direction?
Inappropriate is obviously a value judgement. Who decides? Well, I do, since it was my post. In general, I'd expect that the team would decide, though in my experience there aren't that many teams with the sort of culture that allows this.
But, yeah, I agree with this.
(BobHy) OTOH, even when we consider cleverness whose only benefit is to amuse its author, it's fair to ask whether the author's happiness is itself a benefit to the user community ("a happy programmer is a cooperative, bug-fixing programmer") or to the team ("a happy programmer remains on the team and trains his/her successor").
An ancient Chinese programmer once said,
I pity the fool who has to maintain or extend the code of a programmer who wrote clever code because it made him happy.
I've experienced many cases where a developer writes code that is clever, moves on to another job, and then the people who have to deal with the code have to deal with that cleverness. My current team is dealing with this now, and it's a big problem for us.
If you want to amuse yourself writing clever code, do it on your own time. But don't make your team deal with it.
(BobHy) I'm beginning to think "inappropriate cleverness" may be a vacuous term. But there certainly is "incorrect" cleverness, where the claimed benefit of the design is refutable.
You are obviously not a long-term reader (assuming, for the sake of argument, that such a person exists) if you find the presence of a vacuous term in a post of *mine* surprising.
The difference between inappropriate and incorrect seems mostly one of semantics. I chose inappropriate because I think it's more of a judgement call, while incorrect implies a black and white choice.
(Tomer) It's funny, I keep running into arguments as to the pros and cons of the sort of "codespace-optimized" loops you mentioned. I'm actually very much for them - they're usually used where the algorithm is very simple (for example, when writing to a frame buffer and adding a stride value to your target pointer) and tend to make the code "look" a lot more elegant.
I will confess to being somewhat of a code aesthete in my earlier days, looking for more compact expressions. I got started in that back when I was writing games in interpreted basic, and the size of your code could have a big impact on how fast your program ran.
Over the years, writing a lot of code and trying to understand other people's code, I realized that the #1 most important feature of well-written code is clarity. And for me, the two most important facets of that are:
- Predictability (the code in method a looks like the code in method b)
- Simplicity
The world where for loops just do looping is a conceptual simplification over the world where they sometimes do additional things. In the first case, I read the for statement once, and then concentrate on the loop body. In the second case, I read the for statement, read the loop body, but have to remember that there's something else going on that I have to go back and refer to later. When you write that, you're making me work harder, when you simply could have put "j += stride;" as the last statement in the loop.
That's why foreach is such a useful construct. It's not that you type less. It's that it's conceptually simple - you know that there's no funny business going on, and all you have to worry about is the loop body.
(Shahar) We used to have a dev in a previous company I worked at (circa 2000) who had his own special way of doing HRESULT-COM error checking..
Shahar goes on to detail what the practice was, which I agree is bad, but it's a matter of degree, since all HRESULT handling techniques suck.
*****
Most code is read far more times that it is written. Go read this post by Peter Hallam, one of the C# compiler devs.