[crote]

"Clever" code is an anti-feature.

Writing code is already hard enough as-is due to the complexity imposed by business requirements. On top of that, reading and debugging code is significantly harder than writing it. It is extremely easy to end up with an incredibly clever codebase, which in practice is just a completely unmaintainable mountain of technical debt.

Take for example something like the Fast Inverse Square Root algorithm [0]. It is incredibly clever, but if you randomly come across it most developers won't be able to easily understand how it works. The well-known variant uses undefined behavior, gives a suboptimal result, and doesn't have any meaningful comments. In other words: it cannot be maintained. Having one or two of those in places where they are absolutely necessary isn't a too bad, but imagine having to deal with bugs in a codebase where you come across stuff like this every single day.

Writing clever code is easy. It is far harder and way more important part to write simple code.

[0]: https://en.wikipedia.org/wiki/Fast_inverse_square_root

[kccqzy]

That's not an anti-feature because of cleverness. It's a failure of engineering. Just like everything else, clever code needs to be encapsulated behind a good interface, be well documented, be well tested.

> if you randomly come across it most developers won't be able to easily understand how it works

So document it.

> uses undefined behavior

So fix the undefined behavior. Use memcpy or bit_cast.

> gives a suboptimal result

That's probably intentionally sacrificing accuracy for speed. Document it.

> doesn't have any meaningful comments

Then add it.

Clever algorithms is never the problem by itself. It's undocumented unencapsulated clever algorithms with unknown bugs.

[dwattttt]

Maybe the best example of this would be memcpy. It's extremely clear what it does, but the implementations would surely be "clever" code. And yet you don't need to know anything about SSE to use it.