This isn't about the indentation. Look at the examples. you can see that allot of his code is indented heavily.

This is about the amount of time and distance required to scan my eyes across a line to understand its meaning. How much do I have to read to understand a simple concept?

This is also about the amount of screen real-estate i have to use. We arn't programming on VT100 terminal any more, damn right. NOW I get to have the compiler output and continuous integration output to my left. The directory, class structure and documentation to my right.

I also get to split my screen to have two editors open for comparing snippets of code line by line.

Merge conflicts and diffing are hugely common operations. merges have three parallel windows open at once!

You, still, only have 80 characters to work with.

    This isn't about the indentation.

From TFA:

    Also, having the mandatory indentation whitespace increase the line width is a good visual way of minimising the nested loops in your code and suggesting, in a subtle way, to refactor anything that is indented more than about four times.

Your line from TFA is 241 characters, making it a pain to read....

yah, but I think the author is arguing side benefits.

to be fair, so am I.

The author was asserting 80 character line width was easier to read.

> 80 characters is an accident of history

So are many useful inventions.

The reason it matters is readability. News papers for example have been using columns for readability and to me that makes it easier to read.

Having the same for code is great.

I have 3 vertical monitors so I want to have as much of the code go vertically and then I split the monitor into 2 or 3 columns (vertically), I find I get much better productivity, and my eyes get less tired. I like scanning up and down not too far to the left of right.

I have not always followed this and looked at some old code with 160+ long lines in some places.

Besides terminals are still used when logging in via SSH into a server it is still nice to not to have to keep re-sizing the terminal according to whatever the largest line is.

I don't think long lines that are broken in the middle at 80 characters are more readable than single line that goes to slightly more. Readability in code is not about having a pleasantly looking paragraph (paste some code into MS Word and see how readable it is). Readability is about conveying logical structure through form. A statement is in one line because it is doing one thing.

No, but long lines that are broken intelligently so as to fit in an 80-character wide space are easier to read than a single line.

    MyObject object = MyObjectBuilderFactory.getBuilder().essentialProperty("the value").otherImportantProperty(42).specialThingyReference(someVariable).build();

vs

    MyObject object = MyObjectBuilderFactory.getBuilder().
        essentialProperty("the value").
        otherImportantProperty(42).
        specialThingyReference(someVariable).build();

Or how about:

    cookies = responseObject.headers.findAll { header -> header.key == "Set-Cookie" }.collect { cookieHeader -> new Cookie(cookieHeader) }

vs

    cookies = responseObject.headers.findAll { header ->
        header.key == "Set-Cookie" }.collect { cookieHeader ->
        new Cookie(cookieHeader) }

Just because it is one statement does not mean it has to be on one line.

I would find your first example very readable on multiple lines (it lends itself naturally to breaking up), but only if you go all the way and break on every dot. As it is, it looks asymmetric, like something an automatic word wrap would do and it is very easy to miss that last build() statement when scanning.

But second one looks like a mess either way :), partly because I am not familiar with the language, but mostly I think because brackets are opened and closed on different lines.

I'm sure you can come up with several pretty ways of breaking up every specific situation that is both aesthetically pleasing and functional (in fact I already use your first example, with slight modifications), but there is no general way that can be encoded in rulebook or indent rules of an IDE.

> I'm sure you can come up with several pretty ways of breaking up every specific situation that is both aesthetically pleasing and functional (in fact I already use your first example, with slight modifications), but there is no general way that can be encoded in rulebook or indent rules of an IDE.

Sure, but there are always edge cases not covered by the rule book or IDE. For me the rulebook should say "break lines so that no single line is > 80 chars" and leave it to the programmer to do so in an intelligent way for each scenario. Or if you want a little more conformity add some guidelines like: keep a method call on one line if possible, keep each method parameter on one line if possible, when breaking a method call over several lines vertically align each parameter (indenting when a parameter consists of a long method call itself), etc. You can cover the majority of cases. Examples are helpful.

This:

    return calculateFirstPart(commonObject, dataObject) + 
           calculateSecondPart(commonObject, aDifferentDataObject);

instead of this:

    return calculateFirstPart(commonObject, dataObject) + calculateSecondPart(
        commonObject, aDifferentDataObject);

This:

    computerExplainToMe(
        "Why are all my identifier names are so long?",
        currentKnowledgeEngine.selectedExplanationType,
        KnowledgeContext.getContextForEngine(
            currentKnowledgeEngine, Language.English),
        "Why is this parameter here. I don't even know what it does")
    

instead of this:

    computerExplainToMe("Why are all my identifier names are so long?",
        currentKnowledgeEngine.selectedExplanationType, KnowledgeContext.
        getContextForEngine(currentKnowledgeEngine, Language.English), "Why " +
        "is this parameter here. I don't even know what it does")

The thing about long lines of code is that they almost always contain multiple ideas compressed into one (variable assignment, retrieval, lookups, conditionals, etc). In most programming languages we could put the whole program on one line if we really wanted to. When I see a line that is > 80 characters it makes me think I should be breaking that line up into multiple statements anyways, but depending on the language we may be saving ourselves some boilerplate or sometimes actual resources by putting it all in one line. So intelligent linebreaks are a good compromise in my opinion. We can still separate the individual expressions into readable chunks, but keep the whole expression more tightly packaged (physically and mentally) than it would be if we broke it out into multiple statements.

Just for fun, here is maybe a better way to write that second one:

    cookies = responseObject.headers.
        findAll { header -> header.key == "Set-Cookie" }.
        collect { cookieHeader -> new Cookie(cookieHeader) }

I mostly agree, but I find the effort to properly format broken long lines and to maintain the format when moving code around is sometimes too much. Most editors will indent the continuation by one position like in all your examples, but that is not always what you want (for example a nested call you'd want to indent further). So every time you move the code or copy function call it has to be reformatted manually (especially if one has a slight OCD :)).

This potentially leads to people simply breaking in an arbitrary place, making code less readable than without a break.

(Last example does look better. :))

You're assuming a proportional font, and English language keywords.

What about?...

我品 品= 我品做厂.受做().必要产("the value").别重要产(42).特别Thingy提交(任何变量).做()

...and...

饼干s= 响应品.首s.找都{首→ 首.钥匙 ≡ "Set-Cookie"}.收集{饼干首→ 新 饼干(饼干首)}

They're on one line and more people can read it than your English version.

I guess 80 chars is a rule for latin alphabet based code. A similar rule for chinese would be "whatever historically didn't fit on printed media in country of origin". :) If there are historical parallels at all that is.

I think it is not optimal to easily convey logical structure when code spans long lines left to right. If all the lines are consistently above 120 characters or so, it it is a smell test for bad code (or maybe the wrong language or framework).

Having a consistent width also means not having to rely on a randomly chosen width of the editor and then have random wrap-around code or having to resize the window horizontally or scroll horizontally when also scrolling vertically.

Most good editors will handle well multi-line splits. I use emacs I know it does, it would be silly to use MS Word to edit code.

When I started out I didn't follow the 80 column rule it is something that came with experience (also being able to afford a better monitor, paradoxical perhaps, but once I could open two windows side by side, I wanted to be able to not having to scroll either horizontally).

“80” is an accident of history, but “around 80” is not; it's a product of centuries of experience with reading.

Grab a novel. I bet the line width is closer to 60 characters. Horizontal scanning is hard on the eyes.

Luckily, most code is indented 1 to 4 levels at 2 or 4 spaces per indent. This means that typical code width is limited to be anywhere from 78 to 64 characters wide. That's 77 to 63 if you're actually going with 79 characters, which is what PEP8 et al suggest. Much closer to the 55 to 65 characters of the two or three books I just checked.

You're quite right. The ‘accident’ of 80 comes from the ability of a typewriter to space into what were usually margins.

It is the hjkl of line length.