[phomer]

Oddly, good communication is nearly the complete opposite from good code. Your code should be boring, consistent and obvious. It makes it easier to fix that way. Writing should vary, be inconsistent, approach things from different angles, and often be redundant. It needs to be messy enough to keep the human mind interested; although too many little irritants like spelling and grammar can be disruptive. Some structure is good, but too much spoils the flow. It's a balance.

[derefr]

Something in my intuition says (though I'm not sure if it's to be trusted), that if your code has the chance to be any of those things, you aren't writing it elegantly enough. The best code I've seen reads as a set of revelations (macros) followed by one short, simple bit of glue that feeds library functions to them. (Of course, those building libraries might think differently.)

[phomer]

The stuff I've always liked is usually really obvious. For example, if it's complex tree code, you don't have to spend a lot of time digging into the details; what the code is trying to do is obvious by its steps. Clean, clear, simple and consistent. Boring is an unfair categorization. I meant it in terms of not being clever, but it is really an attribute of the observer, not the code.

The best test I think is in how fast you can make a meaningful change to the code, without having ever seen it or studied it before. In a practical sense, that is the only metric that matters anyways. We write this stuff, so we can maintain it and keep it running. It's not the first version that matters, it's the whole life span.

[derefr]

I think we agree here: you're talking about "complex tree code", which, for me, is the realm of libraries, not applications. Those are allowed to be boring (and thus perfect), predictable (and thus with a clean API), and so on.