Do not disagree at all. I almost always lean towards readability so I can make the next poor soul understand it (usually me 6 months from now). I once ended u

Do not disagree at all. I almost always lean towards readability so I can make the next poor soul understand it (usually me 6 months from now). I once ended up with one of those 'clever' bits of code. It was the best solution because of the constraint we were in. But a co-worker (who helped create it) put it best 'no damn way are any of us going to be able to figure that out 6 months from now'. He was perfectly right, and it did take me 2 days to untangle it about a year later. That was comment time to for future me to put in what was this thing doing and why it worked the way it did (lesson learned). Getting that 'terse'/'readable' balance right can be tricky. Usually if some code is 'hard to read' it usually means it needs a bit of refactoring to shorten/length it up and make clear (with comments) what each bit is doing. You go drop something like duffs device into the middle of a parser you should put a comment on that. As not everyone has heard of it. If the code is going to be used a couple of times a year and if it takes an extra 15 seconds, so what. Comment it with 'hey this would be a good spot for duffs device?'. Most of the type of code I write these days runs so rarely and can take a bit of extra time. I am also working with jr devs who may or may not have read up on every cool trick. I am also playing with some code I got from the net. Some of these things have 5 page long functions, yep... totally lost in abstraction.