0

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);
12
  • 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, 2020 at 17:10
  • 1
    @Steve my threshold ends at 80 columns. I like code I can print without forced wrapping. May 20, 2020 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, 2020 at 19:38
  • 1
    Yes it is. 80 columns. If you don’t like it work on documentation. May 20, 2020 at 20:16
  • dafuq dis is not opinion bsed!
    – 94239
    May 20, 2020 at 20:29

1 Answer 1

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 refactoring1.

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.

15
  • 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? May 20, 2020 at 14:48
  • 1
    @RobertHarvey look again. This isn't a declaration. It's a call. For a multi-line declaration example see this May 20, 2020 at 14:50
  • 1
    Presumably you would use the same style whether it's a function call, declaration or implementation. May 20, 2020 at 15:08
  • Eh, NVM. We programmers do love to bikeshed these things. May 20, 2020 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. May 20, 2020 at 15:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.