Enough whitespace already

In most sensible languages the compiler ignores whitespace; it’s only there to help humans understand the code. The trouble is, without automated checking of whitespace it’s very hard to have consistent style. Without a compiler telling you when you get it wrong, it’s hard to enforce a standard. Sometimes it leads to bugs and, ironically, hard-to-understand code. Maybe it’s time to realise that formatting of code is different from its semantics. Maybe in the 21st century, programmers should be using more than just a text editor?

No Whitespace

For example, the following is perfectly legal Java:

public String shareWishList() {
    User user = sessionProcessor.getUser();  WishList wishList =
    loadWishList.forUserByName(user, selectedWishListName); for(
    String friend : friends)  { if ( !friend.equals("") )  { new
    ShareWishListMail(  friend,  user,  wishList,  emailFactory,
    this.serverHostName ) . send();   }   }   return  "success";

But most normal human beings would much prefer to see this written the “traditional” way, with line breaks in appropriate places and sensible use of the space character:

public String shareWishList() {
    User user = sessionProcessor.getUser();
    WishList wishList = loadWishList.forUserByName(user,
    for (String friend : friends) {
        if (!friend.equals("") ) {
            new ShareWishListMail(friend, user, wishList,
    return "success";


Of course, most IDEs can reformat code for you. And with careful tweaking of the settings you can get something useful. But there are always cases where you want to do something different, to help readability.

For example, I often format uses of builders differently to other code. While I might normally prefer long lines to be wrapped and continue to the line break on the following line, when calling a builder it makes it hard to read:

Trade trade = tradeBuilder.addFund(theFund).addAsset(someAsset).atSharePrice(2)
    .withComment("This is a test trade").forUser(myUser)

This is about a billion times easier to read as:

Trade trade =
                .withComment("This is a test trade")

Test Setup

Tests seem to end up particularly dependent on whitespace. For example, in my current job I recently had cause to try and write something like the following:

var sharePosition = CreateAnnualSharePosition
    .Quarter1Shares(0)        .WithQ1Price(1.250, GBP)
    .Quarter2Shares(10000)    .WithQ2Price(1.15,  GBP)
    .Quarter3Shares(1000000)  .WithQ3Price(1.35,  GBP)
    .Quarter4Shares(1000000)  .WithQ4Price(1.45,  GBP)

Because I had several similar tests, with subtle variations of share count & price quarter-to-quarter it massively helped me while writing it, to have it clearly laid out – so I could see when share count had changed and when price had changed. Unfortunately, VisualStudio had other ideas and removed some of my whitespace when copy & pasting this, which led to me reformatting every damned time.

Internal DSL

Effectively these builders are a form of internal DSL. You’re (ab)using the source language to provide a domain specific language to let you describe what you want to actually do. My previous company used a home grown Java based BDD framework – Narrative. This leads to very fluent acceptance tests, but lots of method chaining. As with the builder pattern this would be totally unreadable without liberal use of whitespace. Take this not particularly unusual example:

                  .for_amount(150, gbp())
                              a_trade_selling("Sub asset 1"),
                              a_trade_selling("Sub asset 2")),

Now, there’s a very particular “style” to how this is laid out. Whoever thought this looked clean and readable (probably me) was clearly on something that day. But it’s difficult to lay out a “sentence” like this because of the massive amount of nesting inherent in what it’s saying.

How can we possibly define rules for whitespace to layout such statements in a clear, readable, machine-enforceable way? After months of seeing different people spend endless hours tweaking whitespace to their own personal preference you know what I realise? You can’t automate it.

So maybe we’re trying to solve the wrong problem? Is the fact that we’re so reliant on whitespace to make code not look like total shit, a hint that maybe our text editor isn’t giving us the expressive power we need? Maybe, just maybe, in the 21st century, programmers could be using something richer than a text editor? Maybe there’s some structure in our source code that we could show better?

Builders – Revisited

Let’s go back to a simple example, my trade builder. Wouldn’t this be easier to read if it was written in the table it so obviously is?

Trade builder

Shock! Horror! Fancy that! Source code that’s not just plain old text but – OMG – a table. The humanity of it! Sacrilege! Giving programmers powerful, expressive, rich text instead of a dumb old text editor.

My share position builder is helped even more by being expressed in a table:

share position builder

But what about the complex set of nested matchers?

Here the nested structure is clearly visible, there’s no need to rely on whitespace – the nested structure is clear and unambiguous. The editor understands the structure and renders the correct layout making it easy to write and much easier to read. It actually becomes impossible to indent things wrong accidentally: a nested table is either nested or it isn’t.

But… how would it work?

Well, obviously our editors would need to be more powerful to support this. The indentation can be derived from the source code: the editor can parse brackets much more easily than the human eye and translate that to a more structured form that’s easier to read.

The critical part is defining the presentation style when declaring a method/class – e.g. identifying builder methods so we can present more naturally.

Would it work?

There are numerous implementation details – but I’m sure it could be made to work easily enough. But, is the complexity worth it? Am I stark raving mad or is it about time our editors were dragged kicking and screaming into the 20th century?

5 thoughts on “Enough whitespace already

  1. Interesting post. In general I agree that IDEs need a bit of rework in that although they have evolved quite a bit on other aspects – refactoring capabilities for one – they aren’t helping much when it comes to code layout. On this side one cool evolution would be an IDE that didn’t need to change the contents of the source file when the user asks it to reformat the code according to the layout rules he chose, but instead simply adapted the visualization so that everyone would look at the source code in a way he likes without forcing his style preferences upon the others.

    Coming to the builders/dsl thing instead, what comes up to mind by looking at your examples are acceptance test frameworks like FIT, that allow you to lay out test inputs in tables. It’s true that they are not really suited for unit tests and probably a pain to deal with if you’re trying to to TDD nonetheless.

    Another approach could be that of using an external dsl, which would eventually have the advantage of being compact and readable since written ad-hoc for the purpose, but writing an external dsl requires effort and the cost is usually not justified.

    Finally, for very specific cases if may be feasible to write an IDE addin which showed the code in a certain way, even in tabular format. That would be an interesting exercise.

    1. Hey Simone,

      Thanks! Re: IDEs auto-reformatting code. There is/was a setting in Eclipse to do just this. It is almost universally hated. The trouble is, IDEs can’t know how to format code /correctly/. That might work, if the meta-data was present to tell the IDE that this class is e.g. a builder, presented in this way – then it could auto-format code more sensibly. Allowing developers to define rules and hints to help the formatter.

      The trouble with FIT and other external DSLs is that you lose the power of your IDE. I like intellisense. Its awesome to have a turing-complete language to express any solution in. When you start creating your own external DSL, you lose all of this. Sure, you can create editors – I’ve even seen automatically configured editors for external DSLs, but then you start having to define /grammars/ and other such geekery.

      I’ve contemplated writing the IDE addin. I’ve written plugins for eclipse in the past, but getting stuff *into* the existing source code editor is tricky. But, absolutely, a proof-of-concept would be great. Once I get my free time back…

  2. I would say – was bit shocked to see Table as a medium to express builders but once it sunk in – Its actually a good idea !!

    Anything which can improve readability should not just be discarded as fancy stuff .

  3. I think it’s a great idea.

    Guess that’s what annotations are for. If we can markup classes/methods/fields to indicte what they are then IDE’s could use these to provide more custom formatting as suggested. In some cases this wouldn’t even be required, simply the name says it all. If we see the word ‘Builder’, ‘Bean’, ‘Dto’, then well we know what it’s about. It would also encourage people to use consistent naming as things would simply just work without the need to annotate things.

    For classes marked as ‘beans’ the IDE could show property name/values in a table, meaning no more lines and lines of boring getters/setters

    Maybe a common set of annotations would allow cross IDE support. Each IDE could then run a custom plugin against each annotated (or auto detected class) and do it’s thing.

    This would also allow better ‘overview’ views. Showing all the beans, or all builders. Anything not these would be ‘interesting’ as they contain the custom logic.

    The same approach could be used for auto generating all those boring getters/setters, builders, validators, toStrings.. etc. If an additional field is inserted on a bean, have the getter/setter auto generated, along with the builder update, toString update etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.