I’ve been on job interviews where the interviewer writes the equivalent of char *(*(*a[])())() on the whiteboard and asks what it declares.

I usually answer that I could probably figure it out but I’m not going to try.

If we, smart as we are, have to scrunch forehead to decipher a line of code, it’s probably a mistake to have written it that way.

If it’s unclear to you now, it will probably be less clear when you look at it again in six months. Less clear to the engineer who has to fix it after you’ve moved on. That way lies bugs.

Further, if the code relies on an advanced or obscure feature, who says that feature works correctly? It’s probably also a confusing facet of the language for whoever wrote the compiler code. And their interpretation might not match what the standard actually requires. Or how the authors of another compiler interpret it.

Let alone whether you can readily translate your approach into another language. Which is handy.

Sometimes a complicated construct really is the best solution. When it is, write as clear a comment as you can that explains what it does, why it’s correct, and why apparent alternatives wouldn’t have worked.