Over at lesscode, Alex Bunardzic is asking:
Now, that’s an interesting way to look at the problem of understanding the code. Would you agree that the more verbose the source code is, the easier it gets to understand it?
Finally (and inevitably), the sacred cow of corporate computing (Java) is dragged in to demonstrate the benefits of verbosity as a feature that encourages reusability through increasing the level of abstraction.
I don’t consider verbosity itself to be a problem.
I’m glad we moved to long variable and method names, away from the short and cryptic C code. Documentation adds to verbosity, so do unit tests, but they both help in code maintenance and evolution. Keeping methods smaller and building for reuse tends to increase verbosity. Error checking and recovery add weight to the code.
Yet, all of these are indicators for good code quality: they add to the code.
Verbosity itself is not an issue, but two aspects of verbosity are: redundancy and repetition. Redundancy results in layers of code that hides the essence of the algorithm. It takes more time to set up the stage before you can get to the actual logic, there’s more places where things can get wrong, and it’s harder to distill the application logic when it’s hidden in pages and pages of redundant code.
Redundancy is definitely more pronounced in Java than in dynamic languages. Java’s approach favors minimalism of the language, whereas the LAMP languages favor minimalism of the code.
Repetition leads to the same information being repeated in code, in objects that control access to the code (EJB), in binding files, configuration files, build files. It’s not uncommon to find the same piece of code described in five different places. That’s a form of verbosity that doesn’t add to the code, but makes the code less accessible.
Repetition is not specific to Java, but it is a problem of J2EE. The intentions are good: platform, language and protocol neutrality. But is the resulting complexity worth the gains? I had vested interest in seeing this approach succeed, but now I consider it a failed experiment that ended up missing its key design objective: easier code maintenance.
Like verbosity, abstraction is neither black or white. Abstraction results in reusable code, in putting focus on the algorithm, in breaking up complex problems into layers that are easier to develop and maintain. But too much abstraction leads to redundancy, repetition and SphagettiO.
It’s forced minimalism in one part of the solution — be it the language, the libraries, or the code — that tends to lead to complexity everywhere else. The elegance of a language is a fine problem to solve in isolation, but as software engineers we need to look at the overall picture. It’s time to reconsider Java and look for better alternatives, but it would be a mistake to react to Java’s forced minimalism by siding with a different forced minimalism.
What we should be looking for is not minimalism of language or code, but simplicity of development, delivery and maintenance.