5 ms·

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 = MyObje

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.

vorg 14y ago
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.
- UnFleshedOne 14y ago
  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.
UnFleshedOne 14y ago
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.
- jdbernard 14y ago
  > 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) }

vorg 14y ago

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.

UnFleshedOne 14y ago
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.

UnFleshedOne 14y ago

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.

jdbernard 14y ago
> 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) }