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.