Noel Rappin Writes Here

All your blocks should have whitespace…

After two blog posts where I was very non-doctrinaire about really big topics, today I’m going to be absurdly doctrinaire about something trivial.

Yep, it’s The Continuing Adventures of the Person Who Cares A Little Too Much About Whitespace.

There are about four things that I do which appear to be different from the work setup of nearly every other developer I’ve ever worked with:

• I use fairly large fonts, about 20 or 22 point
• I’m pretty aggressive about keeping lines to 80 characters
• I tend not to have multiple code windows open at the same time — most of the developers I work with tend to have multiple split panes open. (I do use two monitors when I can so I can see a terminal, browser, and code at the same time, but usually only one code pane)
• I code in dark text on a light background.

The last one I’m prepared to say is just a matter of taste, plus maybe some astigmatism on my part that makes reading light code on a dark background genuinely hard to read.

What I like to think is that I’m not just getting old or indulging in my crazy quirks, I’m actually working in a way that increases focus and removes distractions. When coding, there’s a huge range of potential details to worry about, and I find that I am most successful when I do a good job allowing myself to focus my attention on the small piece of code that I’m working on directly.

One of the goals of a successful application architecture is to allow this kind of focus at the level of business logic, to allow you to work on one part of the code without worrying about the details of other parts of the code. On a small scale, code readability has the same effect, allowing me to work on the thing I’m working on without being distracted by other details.

Which, I guess, explains the big fonts and single window. Big fonts limit the amount of code on the screen at once. You think this is a bad thing, but I’m here to tell you it’s a good thing. Limiting the amount of code on the screen encourages small methods and classes that will fit on the screen. (Checking… in my current editor setup, I can see 25 lines at once on my monitor).

A lot of readability is consistency, which is why I’ve embraced Rubocop even though I don’t love all the rules. Being consistent limits the amount of mental effort you need to figure out the code, again allowing you to focus your attention.

But that’s all big, and I promised doctrinaire and trivial.

If you are strict-ish about an 80 character limit you’ll wind up splitting lines of code. Especially if you have long variable names that don’t have abbreviations. (You should have long variable names that don’t have abbreviations).

And so, the Official How to Split Long Lines Handbook by Noel Rappin for an audience of Other People Who Care A Little Too Much About Whitespace. (I know you will disagree — one of the characteristics of caring a little too much about whitespace is that you disagree with everybody else that does…)

You should know I spent a slightly silly amount of time making sure I could actually describe what I tend to do. But I legitimately feel better having created something like guidelines for this.

Here’s the easiest case: a method call with a long list of arguments. (Which might be a code smell…)

a_long_method_call(argument_one, argument_two, third_one, keyword_one: value_one, keyword_two: value_two)

The first thing people often do is split the line with as much text on the first line as possible. In this case (Medium doesn’t quite give me 80 characters per line, but bear with me):

anti-pattern

a_long_method_call(argument_one, argument_two, third_one,
  keyword_one: value_one, keyword_two: value_two)

The problem is that the second or last line line is often very short and gets kind of buried, espeically if you have like four arguments on the first line and one on the second. In a long list of arguments, being able to distinguish them all is valuable.

The next thing you see is the one argument per line, often aligned to the first argument:

anti-pattern

a_long_method_call(argument_one,
                   argument_two,
                   third_one,
                   keyword_one: value_one,
                   keyword_two: value_two)

I have two problems with this.

One is that it takes up a lot of vertical space without much information.

Two is that I don’t like aligning arguments in the middle of the line. This is admittedly a matter of taste. (Wait, I said I was going to be doctrinaire. What I meant was that I’m 100% right.) I want a simple rule: the more indented the code is, the more complex it is. Aligning code to the first argument in the middle of the line defeats this.

What I do:

• Break the line as early as possible
• Double-indent further lines
• Include no more than two arguments on each subsequent line (this is a tradeoff, I find it easy to tell how many arguments there are when there are only two, if there are more, I find they get lost.

The example looks like this.

a_long_method_call(
    argument_one, argument_two,
    third_one, keyword_one: value_one,
    keyword_two: value_two)

You are probably rolling your eyes, but I see this is a reasonably compact block that still lets me easily see each individual argument. If you squint, my way tends to look more like a square, the other ways tend to look like long rectangles.

I handle long method chains or array and hash literals similarly.

However, try as I might, I can’t completely coax Rubocop into doing this. I can get almost there, but there’s a way it handles keyword arguments that I can’t quite override.

Despite that, this is how I try to break up lines. You should try it. Or at least try to think about whether what you do makes your code easier to understand.

But I’m right about dark text on light background. (See, doctrinare and trival. Again!)