So at three columns, justified, the fast readers were slower than the slow readers?!

I'm a fast reader and shorter lines of text seem faster to me since my eyes can chain easily to the next first line of text, where with longer lines I tend to hunt for the next line when I'm done with the current one.

However, I think this has doubtful applicability to code. IMO, each line should be a new thought and code should normally be browsed with word wrap off and lines extending to infinity. Once a thought needs to be explored, word wrap should be turned on, but otherwise not.

I do think it's important that the line express its major intent in the first 80 characters or so, though. Anything beyond that should be either further parameters that are of little importance or a continuation of the thought expressed in the beginning of the line.

I think doing it like that makes it easier for the brain to scan (thought 1, thought 2, thought 3, not thought 1, thought ... er ... 1, thought 2).

Hmm, your conclusion seems strange. Reading speed would increase with longer lines, but not comprehension. That's what the research seemed to say, anyway.

What do we want, code-wise? Should people be able to understand the code, or read it fast?

> Reading speed would increase with longer lines, but not comprehension. That's what the research seemed to say, anyway.

Actually, they didn't find any statistically significant relationship between # of columns and comprehension:

"A 2x3 randomized block ANOVA found no significant main effects or interaction for either justification or number of columns for total comprehension."

Nor was there any statistically significant result for "satisfaction", eg, the reader's opinion of how easy the page was to read. The only statistically significant results were for reading *efficiency*, which they define as reading speed divided by comprehension scores:

"an interaction approaching significance for justification x number of columns was found"

Whether the columns are justified are not turns out to be hugely important!

> I do think it's important that the line express its major intent in the first 80 characters or so

Definitely.

The comparison is a little shaky, because you NEVER see code formatted in multiple columns. What we're really comparing is a single column with long lines, to a single column with short lines. And this study doesn't cover that..

It does, however, provide some decent evidence that arbitrarily short lines aren't *always* superior to long lines.

[Note: I modified my conclusion in the post to clarify this point]

I think we should demand full justification for the VS.NET code editor.

We have standardized on 80 columns because we spend a lot of time reviewing code revision changes side by side using a difference viewer. Viewing differences side by side becomes much easier when the code is written in a narrow column.

"approaching significance"?? That sounds exactly like "insignificant."

> I think we should demand full justification for the VS.NET code editor.

I'm trying really hard to imagine what that would look like.. ;)

> Viewing differences side by side becomes much easier when the code is written in a narrow column.

This is a great point. It's one of my pet peeves, too. Code that spreads out too much horizontally is smelly:

http://www.codinghorror.com/blog/archives/000486.html

The more I think about this, the more I think that code is such a specialized form of writing that none of the typical reading rules apply.

Keeping your lines short is still an important guideline. But arbitrarily refusing to allow any code to extend past column 80 is unnecessarily inflexible.

[updated post to reflect newly discovered SURL study on line legth]

Keeping one's code within a 78 column limit does have the advantage of being rather a lot kinder to those on 80 column terminals when emailing it about than having lines of code either run off the edge of the scree or line break in an ugly manner. Though I suppose this is of only trivial importance unless you're attempting to work with rather oldschool programmers.

I like your blog because it uses the full width of the browser for the text.

Too bad that bloglines makes you scroll sidewise because other elements of the feed such as pictures increase the virtual width and render some words outside of the view pane.

Even I can't believe this high percentage, but I just checked how my main project written in Ruby gets by in line size:

d = '/home/dewd/workspace/pilar'

sizes = Hash.new(0)

Dir["#{d}/**/*.rb"].each{|f|
ts = IO.readlines(f).delete_if{|line| line.strip.size == 0 }.map{|line| line.size }
ts.each{|sz| sizes[sz] += 1 }
}

total = 0
less_than_seventy_chars = 0
sizes.each{|size, n_occurrences|
total += n_occurrences
less_than_seventy_chars += n_occurrences if size < 70
}

perc = (less_than_seventy_chars * 100) / total.to_f

puts '====== Result:'
p 'Percentage of lines with less than seventy chars: %f' % perc
p 'Total of lines: %d' % total
p 'Number of lines with less than seventy chars: %d' % less_than_seventy_chars

====== Result:
"Percentage of lines with less than seventy chars: 95.753574"
"Total of lines: 33016"
"Number of lines with less than seventy chars: 31614"

I'm surprised that you're even comparing text for reading with text for code. I've never seen anyone concern themselves about how _fast_ you can read a line of code. Speed is nothing. Comprehension is everything. And comprehension is much more a matter of what's going on in the line, not how long it is. I would posit that long line of code almost always are less comprehensible than shorter ones because there's more than one thing going on in the line -- nested function calls, ANDed conditions, whatever. Not always, but mostly.

I must say I'm surprised that justified text tests better than ragged text, mostly because the automatic justification algorithms in browsers and in word-processing software can results in some pretty horrible-looking text. (One way typesetters get justification is to split a lot of words so that there are not yawning fields of whitespace in lines, but no automatic algorithm I'm familiar with tackles the tricky job of splitting words.) I notice this particularly, of course, when reading some sort of technical material that's full of method names or URLs or whatever -- ie, words that are long and un-splittable. Those totally hork up justification.

Incidentally, I must respectfully disagree with piyo -- I really dislike text that goes all the way out to the margins. But, you know, different gaps for different chaps and all that.

My preference isn't for a given line length but for the rule "Try very hard not to allow a line of code to extend past the right edge of the editor viewport, avoiding horizontal scrolling."

I find that comprehension drops drastically when I can't see the entire statement at once. Plus, more than once I've been bitten in languages that don't require a statement terminator (VB, etc.) by something off the right edge that I didn't realize was there.

I'll manually wrap statements as they approach the right edge. Granted, the number of columns in the viewport will vary based on screen resolution, etc. Other than the "kids" whose eyes can handle 1600x1200 on a 15-inch LCD, most of the people I work have about the same number colums to work with.

i personally feel that the longer the line is the harder it is to read and comprehend but that may just be beacuse shorter lines are generaly less important than longer lines. As far as in my own code i like having lines of different length randomly in the code because it allows me to scan the file more quickly looking for a set of lines that resemble the block of code i was working on. The mind can match shapes faster than text.

Long lines are definitely a problem when you have two files open side by side. Anyway I think code might have more in common with musical notation than the English language.

There's a pretty big and basic difference between the length of code lines and those of regular text: long code lines are usually long because they start at a deep indentation level, meaning they have a large amount of whitespace on the left. For the purpose of reading comprehesion this whitespace doesn't count. So if the indentation level is six tabs at four spaces, your 100 character line is actually shorter than 80 characters.

Another point is recent popularity of very long names for individual code units, as in Java and .NET. A 132 character line in C++ might be incomprehensible because it contains a dozen different statements and operations, but a 132 character line in Java might well contain just a single method call with elaborate namespace and class names. Should we arbitrarily break up single statements because they're long, even though they're perfectly readable?

For these reasons, absolute character limits on code lines without regarding the concrete circumstances are pointless.

Some programming languages preach indentation with spaces rather than tabs. E.g., Ruby (2 spaces) and Python (4 spaces).

> One way typesetters get justification is to split a lot of words so that there are not yawning fields of whitespace in lines, but no automatic algorithm I'm familiar with tackles the tricky job of splitting words.

Knuth put a lot of work into developing one for English for TeX. Properly rendered fully justified text (as TeX has always done it, and as other document processors are only now starting to do), gives the advantages of both left-justified text and conventional fully justified text.

I suppose it all depends on how trusting you are. If you can be sure that the code to the right of col 79 doesn't contain surprises or bugs, then fine - just scroll down and watch the structure unfold. (Yeah, right!)

Having to scroll left-right is a big no-no. Painful is not a strong enough word. If it's such a good thing to do, why aren't Home and End called PageLeft and PageRight, eh???, eh???!

Seriously though, what we really need is syntax-aware source control. Then you could share code with people whose views were very different to your own. Modern IDEs and refactoring tools are starting to take us in that direction. (Hands up if you use Ctrl-E,D in VS2005)

Or maybe we could just agree to check in in a canonical format. 80 columns, anyone?

When convenient, I format the code in parallel columns anyway, for example:
(short statement) (or throw exception),
(short statement) (short comment)
both of which ensure that other details do not obscure the normal flow of control.

What I noticed while reading this article is the huge impact of ClearType on readability.
The screenshots of the four examples are not rendered using ClearType, where the rest of the page is on my computer. To me it seems that the impact of ClearType is much bigger than the impact of the column layout.

My way of deal with long lines of code, is to use a proportional-spaced font (I use Comic Sans MS). You can view about 120 characters in the space that 80 characters of fixed-pitch would take. It take a bit of getting used to with many years of "code must by fixed-pitch" drilled in our heads, but it does work quite well.

I like the way the new .NET interface allows you to turn on the word wrapping *and* display the wrap icon. This allows to take advantage of the longer line lengths without having to worry about manually breaking the line for readability, especially on the long horizontals.

You have to have a little considersation for others reading your code, but the ability for them to simply resize the code window to their preferred width and have it wrap is a nice touch.

Granted, if your line is 400 characters and it wraps across 5 lines, it's not doing anyone any favors.

It is an established typographic fact that short lines are easier to read and therefore "comprehension" must also rise with reading speed -- in other words the faster you take it in the sooner you can act upon the information.

Justification is a highly complex issue in typography and it is also well understood that bad justification is unhelpful to the reader. This is where good hyphenation comes in; you cannot discuss justification in any context without also taking hyphenation on board.

Justified text with or without hyphenation has no other typographic function, other than to save space on pages, hence keep production costs down. That is why it was invented. However, if you are going to justify then it must be done well and must be accompanied by some equally good hyphenation algorithm. So many typesetting and page layout apps these days take the lazy approach, using less-than-optimal algorithms for both line spacing and hyphenation -- and it shows.

you rule :)

dsfv vvvcxv dfdsfsf

for plain reading, i prefer long and justified lines.. justified because that makes the lines more predictable to me, and long because i can skip more unimportant words and more easily (which is fully automatic). :)
i bet this sounds strange but it works, i'm a very fast reader (in my native language at least).

I dislike very long code lines because they are a complete waste of screen estate. Most lines are quite short, and I prefer to have multiple windows 80 chars wide each. Visual Studio (last time I checked) does not exactly encourage that on big screens, but I'm an emacs/vi guy anyway.

Research into the design of instructional text has been going on for decades and the Wichita result should not be taken at face value.

This story got a lot of coverage, which is fine, but the results are contradicted by lots of other research.

The most important thing is to realize that there is no optimal line length or justification - it depends entirely on what you're trying to do. Best practice depends on the age and ability of the reader, whether you're designing a news report, the warning label for a medication, a road sign, the instructions for an exam, a novel or, indeed, code. Having said that, non-justified (left only), medium line length works well for most things.