Which is better? One line per action or shorter lines?

Question

The first alternative can result in lines that are too long, and so reduced readability in some web browsing.

The second one can result in a better web readability, but might annoy command line debugger users.

Example:

blah_bleh_blih_bloh = something(arg_a, arg_b, arg_c, arg_d, arg_e);

blah_bleh_blih_bloh =
        something(
                arg_a, arg_b,
                arg_c, arg_d,
                arg_e);

At the extremes, a very short call should obviously be on one line, and a very long call must obviously be broken over several. But there is a significant grey area in the middle where it comes down to aesthetic taste in my view. It's the same with English language - a sentence should typically consist of more than one word, but not an unlimited number, but the exact threshold is a matter of taste for a writer. — Steve, May 20 '20 at 17:10
@Steve my threshold ends at 80 columns. I like code I can print without forced wrapping. — candied_orange, May 20 '20 at 17:17
@candied_orange, yes I'd agree that that is a sensible indication of the threshold, but then you get people asking "what about 75 columns?". Also, once a call is broken over one line, then I resort to one parameter per line (unlike the example given). And a typical exception to the 80 column limit is in SQL, where it's relatively easy to consume dozens of columns with indentation - and although any given indented block should stay within about 80 columns, it's not possible to keep the whole thing within the *same* 80 columns. It's all very hard to boil down to fixed universal rules. — Steve, May 20 '20 at 19:38
Yes it is. 80 columns. If you don’t like it work on documentation. — candied_orange, May 20 '20 at 20:16
I guess we don't do coding-style questions anymore. Wonder when that happened. — candied_orange, May 20 '20 at 21:59
@candied_orange, it's not a problem of documentation, it's the nesting of indented blocks. The block itself may be well within 80 columns of width, but (without going and counting) I suspect it's easy to find examples that exceed the 80th column measured absolutely. Certainly 32 columns of indentation is not exceptional, and with two identifiers of length 20 plus an operator and a couple of spaces, you're easily exceeding column 80. — Steve, May 20 '20 at 22:13
@Steve you misunderstand. I don't care how well you make your point. If you don't agree to my absolutely arbitrary 80 column limit unquestioningly then writing documentation is as close as you will ever get to my code base. — candied_orange, May 20 '20 at 22:19
@Steve the joke is that, for legal reasons, I'm not allowed to make it a death threat. — candied_orange, May 20 '20 at 22:21

candied_orange · Answer 1 · 2020-05-20T14:55:35.097

3

One problem with both is the number of arguments. Any more than 3 should make you think hard about refactoring. Humans aren't good at remembering what each position is for when there are this many of them. But, if you're going to do this anyway...

blah_bleh_blih_bloh = something(arg_a, arg_b, arg_c, arg_d, arg_e);

is bad because it's forcing you to use short non-descriptive names for the parameters.

blah_bleh_blih_bloh =
        something(
                arg_a, arg_b,
                arg_c, arg_d,
                arg_e);

is bad because it's jumbled and would need reworking if things were renamed. Always make renaming easy. It's the most frequently used refactoring¹.

blah_bleh_blih_bloh = something(
    arg_a,
    arg_b,
    arg_c,
    arg_d,
    arg_e
);

Done this way names can be long and everything can be renamed without disturbing other lines. That's something users of source control diff tools will appreciate. The indentation reflects the structure so it's easy on the eyes.

Some may complain about the number of lines it takes up but fluffy code wins over compacted code. Sparse over dense is how the agile manifesto put it.

But try to design something better that doesn't need 5 parameters in the first place.

edited May 20 '20 at 14:55

answered May 20 '20 at 14:38

candied_orange

102,279
24
197
315

I gotta confess, I'm not a fan of the third style. It's fine for the forward declaration, but when you get around to writing the actual function implementation, where are you going to put your opening brace? – Robert Harvey May 20 '20 at 14:48
1

@RobertHarvey look again. This isn't a declaration. It's a call. For a multi-line declaration example [see this](https://softwareengineering.stackexchange.com/a/331680/131624) – candied_orange May 20 '20 at 14:50
1

Presumably you would use the same style whether it's a function call, declaration or implementation. – Robert Harvey May 20 '20 at 15:08
Eh, NVM. We programmers do love to bikeshed these things. – Robert Harvey May 20 '20 at 15:08
@RobertHarvey the answer to your opening brace question is on the other end of that link. It was discussed in the comments and the consensus resulted in use of a style from the c2 wiki. Yes it's a bike shed argument, but it's a peer reviewed and resolved bike shed argument. So I'll leave it there. – candied_orange May 20 '20 at 15:11
`is bad because it's forcing you to use short non-descriptive names for the parameters.` <- do you mean the 80th column wrap, don't you? – 94239 May 20 '20 at 15:39
So the point here is, IINM, **have the variable name and the function name in a same line, then have `m` lines for `n` arguments, when you particularly suggest `m = n`.** right? – 94239 May 20 '20 at 15:41
And if so, would you argue whether that is command line debugging friendly or not. thx – 94239 May 20 '20 at 15:43
bear in mind command line debugging will show you a line and won't (for default configurations) show you any additional context unless keystroke or command – 94239 May 20 '20 at 15:45
@94239: The most important rule about coding style is "when in Rome." Do what your colleagues are doing. The second most important rule is "be consistent." If you only follow these two rules, you're already 95% there. – Robert Harvey May 20 '20 at 15:51
imagine none of those rules apply; somehow Rome doesn't exist yet or anymore, and inconsistencies are acceptable if the reason is to go towards some goal. Looking for the remaingin 5% actually :/ – 94239 May 20 '20 at 16:00
Your time would be better spent elsewhere. – Robert Harvey May 20 '20 at 16:05
how would you know? if you mean there is always a Rome, then say clearly – 94239 May 20 '20 at 16:14
@94239 Robert is advising you to be pragmatic. I'll advise you the same. I'll also advise that it's much better to understand why things are done certain ways, their benefits and their costs. "It was like that when I got here" usually doesn't help improve things. It's good to have goals even when nothing is perfect. – candied_orange May 20 '20 at 17:40
Do what your IDE supports. Don’t fight it, you’ll lose. – gnasher729 May 22 '20 at 07:21

Which is better? One line per action or shorter lines?

1 Answers1