As always, Jeff Atwood has an interesting around code being our enemy as developers. His proposal is that code needs to have better ‘brevity’.
I don’t think Jeff is talking about Brevity – and I think he even says that – but about Clarity. Clarity is simple, obvious, and to the heart of the matter. Real clarity is brief, but easy to read. That includes comments, too.
It could be made shorter in ‘text speak’, but how clear are those messages? There is a reason we don’t use 1 letter variable names!
It’s not tiny fragments of obscure code that does massive amounts (yes, I’m thinking of Perl in that, amongst others). And it sure as hell isn’t about lines of code – many languages (with notable exceptions) let you put an entire program on one line. Ever tried reading one? I did – you can’t.
It’s just about being simple, clear, and to the point. It’s kind of like Buddhist enlightnment – someday, with enough practice, I’d might just achieve that.
Unfortunately, I do think that we’re constrained – people often expect very complex things and lots of features from their software, and when people are demanding complex programs, you get complex code. Look at the complexity cost of, say, just having a simple UI for a Windows app, as opposed to a console app.
Some of the comments are very good, too. ‘Mickey’ is right – often, we’re trapped by bloated design. KISS is my watchword (and occasionally gets me a slap too).
Fred Ross is right, too, in his comment about code maintenance – but he does miss the point that often we’re under pressure from the boss to ‘just get it done’, and the idea of ‘get it done, but in a way that will save us time later’, well, usually, that dog won’t hunt.
Someday, we’ll get past the idea of using lines of code as a metric for how ‘good’ code is. I guess the problem is that clarity is more ethereal.
Comments from my old blog:
I agree with most of your points – but diverge in perhaps the same places you might too.
The other problem (at least in my recent experience) is RAD or AGILE development… which often leads to spaghetti code unless the client is willing to pay a huge code tax for re-writing swathes of the project.