In my
previous Java-bashing post, people started to pick the example apart rather than comment on the fact that Java still is missing some very obvious functionality, like closures. So I won’t come up with another example .

Anyway, I asked myself about the “solution” proposed to my little problem to use exceptions. Smalltalk has exceptions, but they seem to be used a lot less than in Java, and one reason could be that my “native Smalltalk solution” can do without throwing exceptions. And, IMNSHO, this is a good thing.

In my philosophy of software development, readability is king. My experience with coding is that code typically is written once, modified ten times, and read a hundred times. So I like to optimize for reading, then for refactoring, and only in the last place is saving a couple of keystrokes important. Note that these goals are aligned a bit - compact, well-factored code costs less time to type in, is easily modified, and usually fine to read.

Here is some code that clearly falls short of the goal:

((List) val.getValue()).add(UserAttributeMask.fromAttribute(att).
getSpecByNumber((Integer) v.getValue()));

I think it’s only partially Java’s verbosity getting in the way here - this is part of a block of code that sticks out in anotherwise simple class and is labeled as needing refactoring attention. However, that block of code is full of template constructs and casts, which is a bit funny because generics promised us to get rid of casts. For what this line of code does(adding a value to a list), there’s a lot of line noise…

(A big sore point in Java, incidentally, is that for what has become a business-oriented language you need to use a surprising amount of code when working with money amounts. It lacks the notational strength to put down a simple VAT calculation like total = net * 1.18 which makes it hard to sit down with a business expert and talk about the code, which is doing lots of convoluted BigDecimal method calls that are far, far away from how the business user thinks…).

Anyway, taking readability as a major point and going back to the example from the other posting, what do I consider more readable code?


checkTheAuthorization.
doTheWork.


or


checkTheAuthorizationAndIfOk: [doTheWork].


The first snippet of pseudocode is not readily understandable without either going to the implementation of “checkTheAuthorization”, where you can read that it throws an exception, or without context like “all authorization functions throw an exception” as a development standard. Still, you’d want to check, maybe, to see whether it actually throws an exception. The second form is readily understandable by even a casual reader (and, as Smalltalk practice shows, that casual reader doesn’t even have to be a developer in many cases).

So even if there is a technical solution to my problem (sure there is - Java is just as Turing-complete as Smalltalk or Assembler, so we can solve the same set of problems in either language), besides the fact that the technical solution would need me to revise the published SOAP interface in this case, it is also less readable. Which is not good. Adding a few simple standard features to Java - like type inference and closures - would go a long way towards helping developers write readable code.

This entry was posted on Saturday, August 26th, 2006 at 6:50 pm and is filed under Kitchensink. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Stumble it!  Post to del.icio.us