Verbosity

By Alex Bunardzic under Languages on 28. December 2005

I’d like to offer several snippets collected from the recent discussion threads on programming languages (regarding conciseness and verbosity). One person wrote:

The important point about verbosity is not the time you spend typing: it’s about how difficult it is to read and understand the code.

To which the other fellow responded:

And verbosity makes code easier to read. I don’t have to know anything to understand the code. Everything I need to know is there in front of me.

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:

The verbosity of Java code also encourages developers to implement more abstractions and reusable components. The ease of coding in some languages often results in more code, in my experience. It’s easier to just write more code than to stop and think about reusable solutions. In Java and other verbose languages, ‘coding for the moment’ is a losing strategy.

Interesting stuff, innit? Do any of you guys agree with this, or have comments to offer?

Comment RSS - Both comments and pings are currently closed.

28 Responses to “Verbosity”

Chris Dent:

I agree with “verbosity makes code easier to read” but style of verbosity is very important. I wouldn’t call the usual Java code verbose. In my mind verbosity is when you make your intent explicit, through the use of good names and good method extraction and minimization of weird magic happening where you can’t easily see what started it. In some cases this might mean more text in your face, but overall the result is less coding.

comment at 28. December 2005
ryan:

Two responses:

First of all, I think verbosity can actually get in the way, because the ‘how’ can obscure the ‘what.’ I’ve seen many cases where I couldn’t understand what some ’simple’ java code was doing.

Secondly, I’d change “The verbosity of Java code also encourages developers” to “The verbosity of Java code also requires.”

Java makes you create abstractions, even when you don’t need them. I don’t like being told what to do (unless I agree with what I’m being told :D).

update: sorry, I mistyped and put ‘encourages’ again, when I meant ‘requires.’

comment at 28. December 2005
Saša Ebach:

I always thought that verbose means superflous. Long method names for example are not verbose. They are good programming style. The opposite would be obfuscation. All those type declarations and castings sure are “verbose”, meaning that, if I could program the same thing without all those declarations (which in some cases may be technically relevant), than they are simply superflous. They are not contributing to the goal of easily readable code. Let’s not forget that in languages like Java, C#, C++, … you do not declare types to make anything more readable, you do so to help “the compiler” read your code better. For the compiler it can not be verbose enough. Dynamic languages like Ruby help you to cut back on this verbosity. And let’s not forget either, like I said above, that in some cases this technical verbosity is necessary.

comment at 28. December 2005
beza1e1:

Verbosity is a good thing as long as it is meaningful. Javas public static void main is just superflous.

Verbosity is good when it can be abstracted away. Most languages (including my beloved Python) make some abstractions nearly impossible. This is annoying and frustrating then.

Java is so verbose, it encourages abstraction after every little step and hence this over-abstractionism.

comment at 28. December 2005
Senko Rašić:

I agree that (some) verbosity is good. Writing “obvious” code when possible is a good practice, as code is both meant for others to read and for computer to execute.

But, I don’t believe that language/syntax should enforce verbosity. In fact, I believe it’s quite the opposite. The more boilerplate code you have to write, the less you’ll be willing to add more verbosity to increase understanding for the reader, and it’s a net loss.

As for the Java argument, I read it as - if it is hard to code in, you will want to abstract everything. I don’t see how this would be a positive argument; and I don’t like the feeling of the language “suggesting” what’s good for me. If I want to shoot myself in the foot, let me!

On the other hand, if the language makes it easy to code in, and the programmer spends more time and makes the code reusable, (s)he has to write even less code.

comment at 28. December 2005
Labnotes » Blog Archive » Forced minimalism is the wrong approach:

[…] 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? […]

pingback at 28. December 2005
Greg:

There’s a great quote from Lord Kelvin that goes something like “Until you measure something, you can’t really say anything about it”. How about some metrics and measurement of “verbosity” and “understanding the code”?

comment at 28. December 2005
A:

Mere verbosity is just that. Structured, intelligent, and appropriate comments and clarity of code is where it’s at. E.K. Ream’s LEO (Literate Outlining Editor) effort at making the most of Literate Programming can be used to make source code as concise and/or verbose as clarity requires, displaying program and systems structure and interrelations in amazing ways. Used it successfully with PHP, Python, REBOL, JavaScript, and things like XHTML, CSS, XML… and not looking back.

Toss in some TXL to convert code between languages and let the fun begin.

comment at 29. December 2005
Matt Good:

Well, if you summarize the first quotation as “Readability counts” then I agree, however I think that the second argument that verbosity improves readability is often wrong. Consider a simple method implemented in Java:
```
public List getIds(List items) {
    List result = new ArrayList();
    Iterator itemIterator = items.iterator();
    while (itemIterator.hasNext()) {
        item = (Item) itemIterator.next();
        result.add(item.getId());
    }
    return result;
}
```
And its Python equivalent:
```
def get_ids(items):
    return [i.id for i in items]
```
The Java version is more verbose, and this may make it easier to understand for a non-Java programmer than the Python version would be for a non-Python programmer. However after a short explanation of Python’s “list comprehension” the Python version is easily interpretable at a quick glance, while the Java version has turned a relatively simple concept into a far more convoluted method than is necessary.

Regarding the argument about Java’s verbosity forcing abstraction, I think that this is also bogus. Java’s rigidity does tend to force top-down API design, which I guess they consider a good thing since the APIs need carefully planned ahead of time. I tend to prefer the bottom-up evolution of abstractions myself, but I think that you can do top-down design in any language if you really prefer that. However I tend to find that despite Java’s verbosity there are plenty of bad Java programmers content to write the same code over and over again without bothering to abstract it. On the other hand programmers that gravitate towards languages like Python, Ruby, LISP, Haskell, and so on, tend to be more aware of the benefits of abstraction and will become discontent with rewriting the same code and use more abstraction to avoid it.

comment at 29. December 2005
assaf:

Greg makes a valid point:

How about some metrics and measurement of “verbosity” and “understanding the code”

I ported over some Java code into Ruby, so for a very small sample size, I’ve seen code grow shorter, and all of what I consider Java redundancy disappear.

As for understanding the code, I’ll have to revisit it in a year from now, when it’s out of my head and see how readable it is. My guess is Ruby won’t beat Java by much.

Those are all interesting metrics, if you’re having a hypothetical discussion. I only care about one metric, which doesn’t measure lines of code, or ease of comprehension or layers of abstraction. It measures results. My metric is the time it takes me to patch a piece of code.

I routinely patch other people’s code in Ruby, Java and PHP. In Ruby it’s mostly under 5 minutes. PHP is sometimes, but not often, harder and takes longer. It’s Java where I may spend a full day on a one-line fix, and where I most often get frustrated and behind schedule.

comment at 29. December 2005
mark:

There is a big difference between “a lot of code” and verbosity. In the course of my work I have come fresh to a number of large java programs and spent a long time tracking through design patterns and abstractions following call after call wondering where the actual code is. Contrasting that with large python programs - even twisted (which is large and complex) is fairly straight forward to follow.

For me verbosity is sensible variable names ( candidate instead of c , index instead of i , etc.), sensible method/function names, sensible file or package names and less of the fancy footwork that programmers often delight in. For example saying while index != 0 rather than while not index. The former says you are explicitly looking for index to reach 0 - the latter could mean that or it could mean that index is set to None or some other value. Its not a big thing but for someone coming new to the code it makes the intention explicit.

Actually I think that is the key: “make the intention explicit” - something I have never found in nearly ten years of working with Java code.

comment at 29. December 2005
Marius Gedminas:

Excellent point, Matt.

comment at 29. December 2005
Danno:

The more verbose a language is the more opprotunity you have to make a mistake interpreting what it means. More than that, the more verbose code is, the more chunks you have to keep in your working memory or refer back and forth across in order to understand the whole picture. Given 4 or 5 lines of code in any language this won’t be too hard, but across 20 lines it gets difficult and if you’re doing things between multiple sections of code, it gets even harder.

I’m sure a lot of the problems with reading code could be solved by adequate documentation, but that’s a crapshoot of course (who knows when the documentation is going to be adequate on code you come across).

I want to clarify that I’m not talking about verbose variable names (actually, I think semantically specific names would be a better way to think about that nut than verbose names), but a language that requires verbose constructs.

comment at 29. December 2005
Greg:

Those are all interesting metrics, if you’re having a hypothetical discussion. I only care about one metric, which doesn’t measure lines of code, or ease of comprehension or layers of abstraction. It measures results. My metric is the time it takes me to patch a piece of code.

I would say that the time it takes you to patch some code you had previously been unfamiliar with is the same metric I loosely described as “understanding the code”. However, if we want to make comparisons, it isn’t useful enough to say that (for example) Ruby is 500 milli-assafs, PHP is 1000, and Java is 10,000. What would be really interesting is to correlate those metrics with another. In this thread, the correlating factor might be “verbosity”. I think that “verbosity” is close, but not quite right. There are a bunch of languages which are much less “verbose” than Ruby, but I wouldn’t care to maintain them. APL, M come to mind.

Also, there’s a big difference of maintainability even within a language. For example, “straight-up” Java vs. EJBs.

comment at 29. December 2005
Max Khesin:

Metrics?
Reminds me of a famous study that showed bug counts were proportional to lines of code, no matter what language. If it’s true, it speaks for itself.

comment at 29. December 2005
Alex Bunardzic:

Danno wrote:

The more verbose a language is the more opportunity you have to make a mistake interpreting what it means. More than that, the more verbose code is, the more chunks you have to keep in your working memory or refer back and forth across in order to understand the whole picture. Given 4 or 5 lines of code in any language this won’t be too hard, but across 20 lines it gets difficult and if you’re doing things between multiple sections of code, it gets even harder.

Ruby on Rails promotes rather excessive verbosity. For example, when reviewing/maintaining Ruby on Rails code, I routinely encounter verbose statements, such as:

validates _uniqueness _of

validates _numericality _of

validates _presence _of

after _validation _on _create

at _beginning _of _moth

has _and _belongs _to _many

To me, these verbose statements are perfectly clear. In my experience, the more verbose, the less opportunity there is to misinterpret the intention. I really appreciate it when a single statement communicates to me what the intent of the code is, rather than having to read through lines and lines of detailed code that is holding computer’s hand, explaining to it every step of the way.

This hearkens back to the Smart Servant concept. If a system that’s installed as a middle man between me and the machine is bent to serve my needs more than the needs of the machine, the system will be verbose. It’ll offer me ways to express myself in a more common-sense manner, which will buy me (and my colleagues) a much needed ease of communication as well as ease of maintenance.

comment at 29. December 2005
The Infotainment Telesector:

Fluent Interfaces, aka Method Chaining

A few folks have been talking about “fluent interfaces”. I first saw this pattern (and it’s Smalltalk roots) described as “method chaining” in Hibernate In Action:

Method chaining is a programming style supported by ma…

trackback at 29. December 2005
Daniel:

Verbose is not Explicit

verbosity makes code easier to read…?
That’s just plain wrong… read more

comment at 29. December 2005
Danno:

Alex, that’s what I would call semantically specific. Making a variable name bigger, longer, and very obvious doesn’t provide a benefit over a variable name that’s just as specific, but shorter and more terse.

If :hasandbelongstomany were changed to :modelhasmanyotherentitiesandbelongstomanyotherentities it would be more verbose and even easier to understand to someone new to the code but it wouldn’t be any more specific.

I’m not saying being verbose is bad in entirety, being just verbose enough is the moving target I want to aim at. And I’m more railing against the sort of verbosity in Java. I still don’t understand having to create a class to run a program.

comment at 30. December 2005
ryan:

By, the way, I own http://sup.rflou.us, should that be pointed at java.sun.com?

comment at 02. January 2006
Seth Thomas Rasmussen:

That last statement about more abstract languages not forcing you to think about further abstraction is missing the point.

The real problem there sits at a higher level. It is the person that doesn’t stop to think about what they’re doing and how it could possibly be better.

comment at 10. February 2006
Patrick Stinson:

To which the other fellow responded:

And verbosity makes code easier to read. I don’t have to know anything to understand the code. Everything I need to know is there in front of me.

This is wrong. To code is to know. I hope he doesn’t really plan to get anywhere not knowing anything. No matter what level of understanding you are shooting for by reading you should always read to understand.

Also, the code will ideally speak for itself. Comments are one thing, but syntax that does not require verbosity is ideal.

comment at 05. March 2006
Alex Bunardzic:

Patrick wrote:

… syntax that does not require verbosity is ideal.

Assembler syntax does not require verbosity. Still, I, for one, wouldn’t call that syntax ideal. Far from it! I think assembler non-verbose syntax sucks.

comment at 05. March 2006
Aristotle Pagaltzis:

I think assembler syntax is perfect.

comment at 07. March 2006
Alex Bunardzic:

Aristotle Pagaltzis wrote:

I think assembler syntax is perfect.

Wow, as they say, there is first time for everything.

I’ve never heard anyone praise assembler syntax as being perfect. I must say I’m intrigued now.

Maybe you could explain how would an equivalent of Rails syntax, something like:
```
validates_presence_of :name
```
translate into the assembler syntax? If that syntax is indeed perfect, as you claim, it should then render something even more expressive and intuitivelly easier to grasp than validates_presence_of (which, for me at least, is as close as I’ve seen a programming language ever come to perfection).

comment at 10. March 2006
Aristotle Pagaltzis:

Why would I do that in assembler?

comment at 10. March 2006
Jules:

To make it fast.

comment at 10. May 2006
Aristotle Pagaltzis:

I don’t remember having a performance problem. Do you have one?

comment at 11. May 2006

lesscode.org

Verbosity

28 Responses to “Verbosity”