Beautiful Code has some really good chapters. I was leafing through my copy recently and realized the chapter on code readability is online, as well as the source code to DiffMerge, discussed in the chapter.
I am personally a fan of 80-column lines, and there is a reasonable defense of it in the chapter:
Book and magazine text is composed in columns, usually in columns far narrower than the page. Why? Because narrowness reduces the back-and-forth scanning our eyes must do as we read—reading is easier when our eyes work less. Reading is also easier when what we’ve just read and what we’re about to read are both within our visual range. Research shows that as our eyes change focus from word to word, our brains can take cues from surrounding, unfocused shapes. The more our brains can glean “advance warning” from shapes within the visual periphery, the better they’re able to direct our eyes for maximum comprehension.
Research also seems to show that, when it comes to line lengths of text, there’s a difference between reading speed and reading comprehension. Longer lines can be read faster, but shorter lines are easier to comprehend.
Certainly we need code to be understandable when we read the source files directly. We also need the code to be understandable when we encounter it in diffs, merges, patches, debuggers, code inspections, compiler messages, and a variety of other contexts and tools. […]
When working on code that changes as often as DiffMerge (it has been changed 175 times since it was first written), programmers spend considerable time looking at it in diff and merge tools. What these tools have in common is that they restrict the horizontal view of source files, and they add a certain amount of clutter of their own. Code like DiffMerge’s is readable even in these conditions. In command-line diffs, its lines don’t wrap. In graphical diff tools, we don’t have to fiddle with the horizontal scroll bar to see the bulk of its lines, […]
Direct link to chapter: http://www.perforce.com/beautifulcode/Code_in_Motion.pdf
Direct link to DiffMerge source: http://www.perforce.com/beautifulcode/diffMerge_code.html
I am personally a fan of 80-column lines, and there is a reasonable defense of it in the chapter:
Book and magazine text is composed in columns, usually in columns far narrower than the page. Why? Because narrowness reduces the back-and-forth scanning our eyes must do as we read—reading is easier when our eyes work less. Reading is also easier when what we’ve just read and what we’re about to read are both within our visual range. Research shows that as our eyes change focus from word to word, our brains can take cues from surrounding, unfocused shapes. The more our brains can glean “advance warning” from shapes within the visual periphery, the better they’re able to direct our eyes for maximum comprehension.
Research also seems to show that, when it comes to line lengths of text, there’s a difference between reading speed and reading comprehension. Longer lines can be read faster, but shorter lines are easier to comprehend.
Certainly we need code to be understandable when we read the source files directly. We also need the code to be understandable when we encounter it in diffs, merges, patches, debuggers, code inspections, compiler messages, and a variety of other contexts and tools. […]
When working on code that changes as often as DiffMerge (it has been changed 175 times since it was first written), programmers spend considerable time looking at it in diff and merge tools. What these tools have in common is that they restrict the horizontal view of source files, and they add a certain amount of clutter of their own. Code like DiffMerge’s is readable even in these conditions. In command-line diffs, its lines don’t wrap. In graphical diff tools, we don’t have to fiddle with the horizontal scroll bar to see the bulk of its lines, […]