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?
I prefer the following
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:
I will try to avoid this, if it happens I will do the following
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.
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.