Where to wrap a line of code, especially long argument lists? [closed]

Answer 1

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.

Answer 2

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);

Answer 3

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.

Answer 4

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, ...);

Answer 5

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.

Answer 6

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.