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
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);
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:
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.
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.
int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1,
Argument2,
Argument3,
Argument4);
或
int SomeReturnValue = SomeMethodWithLotsOfArguments(Argument1, Argument2,
Argument3, Argument4);
取决于列表/参数长度。
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);
int SomeReturnValue = SomeMethodWithLotsOfArguments(
Argument1,
Argument2,
);
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,
);
我将方法串起来，行长度对我来说不是问题。 我有一个漂亮的宽屏显示器，水平滚动条的发明是有原因的。 最重要的是，现在许多 IDE 都具有调用树、查找引用和重构工具等实用程序，因此导航源代码不仅仅是视觉滚动。
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.
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.
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.
someStruct.x = somevalue;
somestruct.y = someothervalue;
int someResturnValue - SomeMethod(somestruct);
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);
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.
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.
发布评论
评论（14）
建议的选项 3
是更好的方法，因为它给人一种良好的感觉。
如果参数的长度或多或少相同，那么我们可以将它们放在一起，例如将它们排列为表格
The option 3 suggested
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
我尽量保持简短。 在这种情况下，我会在赋值之前和每个参数之后中断。 我还将逗号放在行的开头，以便于添加新参数：
在 Visual Studio 中使用这种布局需要大量工作，但 Emacs 对我来说可以自动完成。
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:
Using this kind of layout is a lot of work in Visual Studio, but Emacs makes it automatic for me.
我更喜欢这种方式：
该行的结尾最接近您当前的最大行宽（无论是什么），下一行相对于等号缩进您通常的缩进级别（无论是什么）。
不知道为什么，但我认为在大多数情况下这是最具可读性的选项。 然而，我选择不对这些事情迂腐，我总是更喜欢对于给定的代码部分来说最具可读性的内容，即使这可能会破坏一些缩进或格式规则（当然，在限制范围内）。
一个例子是，如果函数需要许多参数或参数本身很复杂，那么我可能会选择这样的东西： 当然
，如果参数表达式非常长或复杂，最好在函数调用并使用临时值来存储结果。
I prefer this way:
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:
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.
就我个人而言，我不喜欢第二个选项，它太接近 Ascii 艺术，并且在代码中带来不便：更改函数的名称，您必须重新缩进所有参数。 并且不知何故它使文件膨胀。 另外，如果您在代码中使用硬制表符，它的效果就不好。
大多数时候，我使用第一个选项，但我采用了 Eclipse 连续行缩进规则，因为它比普通缩进更突出（特别是如果您拆分条件指令）。
有时我使用第二个选项，例如。 如果左括号已经接近我的行长度限制...
优点：可以在每个参数后添加行注释。
或者我确实喜欢 Dheer，将参数分组，直到它们填满线宽。
参数与函数名称分开这一事实从未困扰过我，它们仍然很接近并且非常分组。 最坏的情况是，我可以在函数调用周围放置空行。
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.
第一，
如果参数足够短并且具有（几乎）相似的长度，我认为下面的视觉效果足够好
第二
当情况变得更糟时，一列参数确实有帮助
第三
但是，现在，如果情况变得更糟怎么办！ 现在怎么办？ 试试这个
顺便说一句，如果您想要一致的外观，请在上述所有条件下使用第三个。
Justify ：整齐地穿上，我们知道这是一个带有大量 (6) 参数的函数调用。 我喜欢我的代码看起来整洁且
!(so_ugly)。欢迎批评。 请评论。
First
If the args short enough and have (almost) similar length, I think below visually good enough
Second
When It getting worse, one column of argument really help
Third
But, now, How if it is worsen! What now? Try this one
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.
在具有长参数列表的函数中，我在每一个或两个参数后面换行以提高可读性（始终在每行上保持相同数量的参数）：
或
取决于列表/参数长度。
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):
OR
depending on the list/parameter length.
对我来说，这取决于参数列表的长度。 我不太喜欢行尾布局，它几乎需要编辑器支持（例如 emacs）才能做好。
如果方法调用足够短，可以将其放在一行上，我会这样做：
如果方法和变量适合一行，而参数适合另一行，我会这样做：
这让我的 LISPy 心微笑，但也激励了我的同事坚果，所以我已经软化了：
我想我只是想说我还没有找到我真正满意的解决方案，尽管这对真正超长的案例有一些吸引力，因为它与我们的布局方式相似卷发：
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:
If method and variable fit on one line and arguments on another, I've done this:
That makes my LISPy heart smile, but drive my colleagues nuts, so I've relented:
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:
警告：我使用 IDE。 如果您不是 IDE 用户，请跳过此部分。
与他人合作时：
我倾向于坚持团队当前采用的任何惯例。 如果团队使用支持代码格式的 IDE，那就更好了。 始终坚持团队/IDE 格式约定。 无法告诉你有多少次我被“version-contro-diff-hell-due-to-reformats”烧伤了
当单独工作时：
我将方法串起来，行长度对我来说不是问题。 我有一个漂亮的宽屏显示器，水平滚动条的发明是有原因的。 最重要的是，现在许多 IDE 都具有调用树、查找引用和重构工具等实用程序，因此导航源代码不仅仅是视觉滚动。
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.
对此我没有明确的答案。 我会根据具体情况进行处理。 如果函数名称很长，我绝对不会将其他参数缩进到与前面的参数相同的列。 如果函数名称很短，我通常会将以下参数缩进同一列，在一行上收集尽可能多的参数（不是一个参数 = 一行）。 但是，如果存在一些令人愉悦的对称性，例如
i 中的对称性，则可能会打破该规则，并且每行上的参数数量相同。
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
i would probably break that rule, and have the same number of arguments on each line.
如果右手边不被破坏，我总是在作业之前休息。
这在 Java 等语言中非常有用，在这种语言中您必须显式声明所分配值的类型。
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.
大多数人都对缩进提出了很好的建议，这对于您无法控制的 API 函数来说非常有用。 如果您确实控制 API，我建议一旦您拥有超过 3 个参数，您应该创建某种形式的结构并将该结构传递给例程。 一旦你得到了以上 3 个参数，以错误的顺序传递它们的机会就会大大增加。 它还使参数的类型和含义更加清晰。
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.
我还使用爱德华·克梅特（Edward Kmett）引用的“一致缩进选项”。 如果有很多参数，我倾向于尽可能根据相关性对它们进行行分组。
但对于这个特定的示例，我可能会将其保留在一行上，它不会那么长。
我无法忍受“悬空换行”格式，因为它很容易造成与（更重要的）缩进相冲突的视觉混乱。 目前，悬挂包裹被认为是许多语言的“默认”样式，但我不知道它是如何形成的。 恕我直言，这太可怕了。
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.
我更喜欢以下
两者彼此一致，当达到 80 个字符时，我进入下一行并放置 2 个缩进，每个缩进 4 个空格。 我对此的论证如下：
我使用 2 个缩进，每个缩进 4 个空格，以便清楚地看到它涉及换行而不是缩进的代码块这一事实。
这种缩进方式可以使代码保持良好的缩进，因为它始终遵循相同的缩进模式，2 个缩进用于换行，1 个缩进用于代码块。
将每个参数放在单独的行上可能会导致非常大的方法，因此我更喜欢将参数按顺序放在一行或多行上。
这种换行方式可以在 Eclipse 等 IDE 中配置，提供自动格式化的能力。
然而，有一个重要的注意事项，在特殊情况下可能会发生以下情况：
我将尽力避免这种情况，如果发生这种情况，我将执行以下
操作是的，我将超过 120 个字符的最大值。 代码行长度约定，我的约定实际上对此很灵活，最多 120 到 140 个字符，通常我在 120 之后换行，但在这种情况下我将使用最大字符数。 140 个字符。 这样做的缺点当然是无法在eclipse等IDE中配置自动格式化。
附： 我知道有些人认为 120 个字符对于代码行长度来说太多了，但那是另一个讨论了。 上述约定当然也适用于 80 / 100 个字符。
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.