As programmers we are often to keep things simple, and not to be too clever. While I agree with these principles most of the time, I hope that they are not used as an excuse to avoid finding better solutions for our problems.

How do we define too clever? If we read a code that we can't understand right away, does it mean it's too clever?

Let's take a look at one of the most clever use of case label fall-through in the history of Computer Science: the Duff's device.

Both clever and confusing, this device leverages C's relaxed specification of the switch statement to optimize a serial copy using loop unwinding. I can imagine most people being repulsed by the code above -- you're not alone. Even the code's discoverer said that he felt "a combination of pride and revulsion at this discovery."

But is Duff's device too clever? I think if you look at it in the original context (which was about real-time animation), it was a brilliant solution to the problem. That is not to say we should start using it in our everday work. Even ignoring issues with how different system architectures and compiler optimizations handle the device, is loop unwinding even useful? Most likely no. There are many ways to get your code to run faster, including new hardware.

How about this piece of code, found in the 3D engine of Quake III to calculate the square root of a float.

Notice the magical constant `0x5f3759df`. Where did that come from and what does it do? There is a brief explanation given here about this constant. Basically it involves the Newton-Raphson method for approximating square roots.

Is this `InvSqrt` function unnecessarily clever? I'd say no, because 3D engines have always used mathematical models to draw speed and power from. This function is pretty straight-forward once you understand the math behind it. And in this case, we can't throw more hardware to increase performance, not unless we want to launch a game that can't even perform at 50% speed on the best gaming-rig currently available. (I'm reminded of Wirth's law a little bit)

The point is, we need to pick and choose when to be clever. Principles and guidelines are useful, but they are not meant to be be followed 100% of the time. Aren't we, as programmers, paid for our ability to think? So think!