[junto]

I guess that concise implementations (e.g. in a one liner) are often a complete bitch to debug when someone else comes back to it to fix a problem years later.

It is much more difficult to debug and fix existing code than develop it from scratch. Hence, if you found the problem hard to code in the first place, then when you come to debug it again later you've just screwed your future self.

[danielbarla]

I've also seen (severe) examples of the converse - e.g. writing an 800 line monster which could better have been expressed as a regular expression (and a simple one, at that).

This leads me to think that conciseness is not necessarily as simple as we tend to think. Sure, overly concise code with clever hacks are often a nightmare to debug, but that's mostly because they are the wrong abstraction and not capturing the problem well enough.

[zby]

The problem with people writing too concise code is with their motivation not with their abilities - and so it is probably impossible to test (at least directly), because on the test they would have the motivation to do the right thing.

[talles]

I disagree.

Knowing how much to abstract and writing clear code is indeed an ability.

[st3v3r]

No. If someone has to be "motivated" to write clear code, especially given that these tests are supposed to lead to jobs, then I would have to question their abilities. Writing clear code is an ability of itself.

[zby]

The point was about code 'too concise' - this is different from 'not clear'.