3 ms·
> 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 alread
by 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) }
- UnFleshedOne 14y agoI 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. :))