entropia

In his latest rant, Steve Yegge asserts that the worst thing that can happen to a codebase is for it to get too big. He uses a lot of words to make his beliefs clear: too much code is bad; most people don’t think too much code is bad; Java, and similar languages, are verbose; refactoring doesn’t help code size. But in all his words, there wasn’t a lot of reasoning behind what he said.

Fortunately, Jeff Atwood condenses and elaborates, and for the most part he agrees. But they both fail to distinquish between bloated code and verbose code.

Bloat is when code is larger than it should be because of repetition, featuritis, or poor organisation. Bloat is the opposite of elegance.

Verbosity is code that is long because the language requires it, or because of design decisions. Verbosity is the opposite of succinctness.

Code can be bloated but succinct. It can be verbose but elegant. And it can be bloated and verbose. Verbosity can be bad, but bloat is always bad.

In Java, and C#, there’s a lot of boilerplate code. A simple property can take up 15 lines on the screen. A map can take 6. Both can be done in a single line in a language like Ruby.

But does that matter? Is that extra code any harder to manage?

One more thing that Steve asserts is that the claim that the IDE can overcome this verbosity is flawed. This is where I don’t necessarily agree. A good IDE can hide a lot of that boilerplate code from you, can do refactorings that would requires managing the code, and, perhaps most importantly, can highlight the code so it’s easier to see the meat.

Steve’s argument is that the power of the IDE promotes even longer code, requiring even more powerful IDEs and creating a vicious circle. This is true, but it’s ultimately up to the programmers and languages designers to keep their code managable. Just because it’s easy, doesn’t mean you should do it.

Yes, less code is better. And being succinct is better than being verbose. But the latter really isn’t that big of an issue.