Where to wrap a line of code, especially long argu

问题:

What's your preferred way of wrapping lines of code, especially when it comes to long argument lists?

There has been several questions relating to wrapping lines (such as When writing code do you wrap text or not? and Line width formatting standard), but I haven't been able to find one which covers where to wrap a line of code.

Let's say we have a line of code that keeps going and going like this example:

int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1, Argument2, Argument3, Argument4);

How should that be wrapped?

Here's a few ways I can think of, and some of their downsides:

int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1, Argument2,
    Argument3, Argument4);

I personally don't prefer that option because the formatting seems to visually separate the argument list from the method I am trying to call, especially since there is an assignment equals sign ("=") right above the orphanged arguments on the new line.

So, for a while I went with the following approach:

int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1,
                                                       Argument2,
                                                       Argument3,
                                                       Argument4);

Here, the arguments are all bundled together, all on the side of the method's first argument. However, one catch is that the argument list won't always line up in the second line onwards because of the number of spaces that the tab indents. (And typing extra spaces for formatting would be too time consuming.)

An answer in the one of the previous questions suggested the following format:

int SomeReturnValue = SomeMethodWithLotsOfArguments(
    Argument1,
    Argument2,
    Argument3,
    Argument4
);

I actually like this format, due to its visual appeal, but it also it does visually separate the arguments from the method that the list belongs to. Also, I prefer to have a single method call not take up too many lines.

So, my question is, without getting into the issue of preventing a code of line from getting too long in the first place, how would you recommend wrapping lines of code? Specifically, where is a good place to break a line of code, when it comes to long argument lists?

回答1:

int SomeReturnValue = SomeMethodWithLotsOfArguments
(   Argument1,
    Argument2,
    Argument3,
    Argument4
);

回答2:

The option 3 suggested

int SomeReturnValue = SomeMethodWithLotsOfArguments(
    Argument1,
    Argument2,
    Argument3,
    Argument4
);

is a better way as it gives a good feel. If the lengths of arguments are more or less same, then we can put them together so that they line up as a table for example

int SomeReturnValue = SomeMethodWithLotsOfArguments(
    Argument1,    Argument2,    Argument3,    Argument4,
    Argument005,  Argument006,  Argument7,    Argument8
);

回答3:

I prefer this way:

int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1, Argument2, 
                        Argument3, Argument4);

Where the line ends closest to your current max line width (whatever that is) and the next line is indented your usual indent level (whatever that is) relative to the equals sign.

Not sure why, but I think it's the most readable option in most situations. However, I chose not to be pedantic about these things and I always prefer whatever is most readable for a given section of code, even if that may break some indenting or formatting rules (within limits, of course).

One example of this would be if the function required many arguments or the argiments where themselves complex, then I might chose something like this instead:

int SomeReturnValue = SomeMethodWithLotsOfArguments(
                        Argument1 + Expression1 + Expression2, 
                        Argument2 - Expression3 * Expression4, 
                        Argument3, 
                        Argument4 * Expression5 + Expression6 - Expression7);

Of course, if the argument expressions are very long or complex it would be better to do the calculations before the function call and use temporary values to store the results.

回答4:

I try to keep the lines short. In this case, I would break before the assignment and after each parameter. I also put the comma at the beginning of the line to make it easy to add new arguments:

int SomeReturnValue 
   = SomeMethodWithLotsOfArguments(
         Argument1
       , Argument2
       , Argument3
       , Argument4
    );

Using this kind of layout is a lot of work in Visual Studio, but Emacs makes it automatic for me.

回答5:

Personally, I dislike the second option, too close of Ascii art, with its inconveniences in code: change the name of the function, you have to re-indent all arguments. And somehow it bloats the file. Plus it doesn't do work well if you use hard tabs in code.

Most of the time, I use the first option, but I adopted the Eclipse rule of two indents for continuation lines, as it stands out better from normal indentation (particularly if you split conditional instructions).

Sometime I use the second option, eg. if the opening parenthesis is already near of my line length limit...
Advantage: you can add a line comment after each parameter.
Or I do like Dheer, grouping arguments until they fill the line width.

The fact the arguments are separated from the function name never bothered me, they are still near and quite grouped. At worst, I can put blank lines around the function call.

回答6:

For me, it depends on just how long the argument list is. I don't like end of line layout much and it almost requires for editor support (e.g. emacs) to do it well.

If the method call is short enough to get it on one line, I'll do this:

int SomeReturnValue =
    SomeMethodWithLotsOfArguments(Argument1, Argument2, ...);

If method and variable fit on one line and arguments on another, I've done this:

int SomeReturnValue = SomeMethodWithLotsOfArguments
    (Argument1, Argument2, ... );

That makes my LISPy heart smile, but drive my colleagues nuts, so I've relented:

int SomeReturnValue = SomeMethodWithLotsOfArguments(
    Argument1, Argument2, ... );

I guess I'm just trying to say I haven't found a solution I'm really happy with, though this has some appeal for the really overlong cases due to its similarity to how we lay out curlies:

int SomeReturnValue = SomeMethodWithLotsOfArguments(
    Argument1, 
    Argument2,
);

回答7:

warning: I use IDEs. If you're not an IDE user, just skip this.

When working with others:

I tend to stick with whatever convention is currently adopted by the team. Even better if the team uses an IDE with code format support. Always stick w/ the team/IDE format conventions. Can't tell you how many times I've been burned by "version-contro-diff-hell-due-to-reformats"

When working alone:

I string the method on, line length isn't a problem for me. I've got a nice widescreen monitor and horizontal scrollbars were invented for a reason. On top of that, navigating source code is much more than visually scrolling now that many IDEs have utilities like call trees, find references, and refactoring tools.

回答8:

There is no definitive answer for me on this. I do it on a case by case basis. If the function name is long, i definitely don't indent the other arguments to the same column as the previous arguments. If the function name is short, i usually indent following arguments to the same column, collecting as many arguments i can on one line (not one argument = one line). But if there is some pleasing symmetry, like in

int a = foo(a + b,
            c + d);

i would probably break that rule, and have the same number of arguments on each line.

回答9:

I always break before the assignment if that leaves the righthandside unbroken. This is usful in languages like Java, where you have to explictly declare the type of the value that's assigned.

SomeVeryVerboseTypeName SomeReturnValue
   = SomeMethodWithLotsOfArguments(Argument1, Argument2, ...);

回答10:

Most have made great suggestions about indenting and this is great for API functions that you don't control. If you do control the API, I would suggest that once you ahve more than 3 arguments you should create some form of structure and pass the structure to the routine. Once you get above 3 arguments the chance of passing them in the wrong order goes way, way up. It also gives more visibility to the type and meaning of the parameters.

someStruct.x = somevalue;
somestruct.y = someothervalue;

int someResturnValue - SomeMethod(somestruct);

回答11:

First

If the args short enough and have (almost) similar length, I think below visually good enough

int variable_with_really_long_name = functionWhichDoMore(Argument1, ArgumentA2, 
                                                         ArgumentA3, Argument4, 
                                                         ArgumentA5, Argument6);

Second

When It getting worse, one column of argument really help

int variable_with_really_long_name = somefunctionWhichDoMore(Argument_Expand1, 
                                                             Argument2, 
                                                             Argument_Expand3, 
                                                             Argument_Expand4, 
                                                             Argument_Expand5, 
                                                             Argument6);

Third

But, now, How if it is worsen! What now? Try this one

int variable_with_really_long_name = someFunctionWhichDoMore
                                     (
                                       Argument_Expand_More1, 
                                       Argument_Expand_More2, 
                                       Argument_Expand3, Argument4, 
                                       Argument_Expand_More5, Argument6
                                     );

By the way, if you want a consistent look, use the third in all condition above.

Justify : Neatly put on and we know that it is a function call with lots of (6) args. And I like my code looks neat and !(so_ugly).

Critics are welcome. Please comment up.

回答12:

In functions with long parameter list, I wrap after each one or two parameters for readability (always keeping the same number of parameters on each line):

int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1,
                                                       Argument2,
                                                       Argument3,
                                                       Argument4);

OR

int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1, Argument2,
                                                       Argument3, Argument4);

depending on the list/parameter length.

回答13:

I also use the ‘consistent indenting option’ as quoted by Edward Kmett. If there are a lot of arguments I tend to line-group them by relatedness where possible.

But for this particular example I'd probably leave it on one line, it's not that long.

I can't stand the ‘dangling wrap’ format as it can easily provide visual confusion conflicting with the (much more important) indenting. Dangling wraps are considered the ‘default’ style for many languages at the moment, but I don't know how it got that way. It's IMHO horrible.

回答14:

I prefer the following

int variable_with_really_long_name = functionWhichDoMore(
        Argument1, ArgumentA2, ArgumentA3, Argument4, 
        ArgumentA5, Argument6);

int i = foo(Argument1, ArgumentA2, ArgumentA3, Argument4, 
        ArgumentA5, Argument6);

Both are consistent with each other, when reaching 80 chars, I go the next line and place 2 indents of 4 spaces each. My argumentation for this is as follows:

• I use 2 indents of 4 spaces each, in order to clearly visualize the fact that it concerns a wrapped line and not an indented code block.

• This way of indenting keeps the code nicely indented because it always follows the same indenting pattern, 2 indents for line wrapping, 1 indent for code blocks.

• Placing every argument on a separate line can result in very large methods, hence I prefer arguments sequentially on one or more lines.

• This way of line wrapping can be configured in an IDE such as Eclipse, providing the ability of auto-formatting.

However there is one important note, there can be exceptional cases where the following occurs:

int variable_with_really_long_name = functionWhichDoMore(arg1,
        arg2)

I will try to avoid this, if it happens I will do the following

int variable_with_really_long_name = functionWhichDoMore(arg1, arg2)

Yes, I will pas my 120 char max. code line length convention, my convention is actually flexible on this, max 120 to 140 chars, normally I wrap after 120, however in this case I will go to max. 140 chars. The disadvantage of this is of course that it cannot be configured for auto-formatting in an IDE such as eclipse.

ps. I know some people think 120 chars is way to much for code line length, but that's an whole other discussion. The conventions above can of course also be applied for 80 / 100 chars.