[segmondy]

This is a very delicate subject. If the program is using language constructs and can't be understood because the reading programmer doesn't know it, then who's fault is it?

why have multiline if/else when a tenary operator can do?

I rather read a = b ? c : d; than possibly 4 lines of code, p/s ignore the names of the variable.

There are plenty of code out there that are so easy to understand if you read them one line at a time, but very difficult to see the big picture, say there is a method being called as follows foo->dostuff(bar).

The issue is there is so many layers between calling dostuff() and something interesting happening. because dostuff calls nextstuff() and nextstuff() calls stuffafternextstuff(). The code is easy to read but terrible and tough to unravel.

There is only so much anyone can hold in their head at once, a bit complex but 2 layers deep is better than so simple to understand one line at a time but 10 layers deep.

[hinkley]

Bertrand Meyer and a few other notables talk about separating decisions (policy) from execution, which happens to address some of those issues, because the decide and act become sibling function calls instead of a deeply nested chain of responsibility arrangement.

It also happens to make testing a lot easier.

It's probably just a crystalization of the old idea of keeping business logic out of your code, but somehow misses the open invitation to create rules engines...

[mannykannot]

There is a tendency for the discussion of complexity in programming to descend into an obsession with trivial minutiae.