C# 编码风格——行长/换行

C# coding style - line length / wrapping lines

提问by Kevin

Does line wrapping help with code readability?

换行是否有助于代码可读性？

Is there a generally accepted etiquette for using line continuations?

是否有普遍接受的使用行延续的礼节？

Why use this:

为什么使用这个：

SomeMethod(int someInt, Object someObject,
   String someString, bool someBool)
{
    ...
}

Instead of this:

取而代之的是：

SomeMethod(int someInt, Object someObject, String someString, bool someBool)
{
    ...
}

Edit: re-worded my question from line continuation to line wrapping

编辑：重新措辞我的问题，从续行到换行

采纳答案by Reed Copsey

Line continuationsare not used in C#, since an explicit line terminator (;) is required.

C# 中不使用行延续，因为需要显式行终止符 ( ;)。

If you're asking, in terms of style, whether it's a good idea to break a line into multiple lines, that's debatable. The StyleCop rules force a line to either be defined on a single line, or for every element to be on a separate line. I personally think this is a good guideline, and I usually choose to break a line completely into its parts if it's too long to fit into a good 80-90 character wide editor.

如果你问，就风格而言，将一行分成多行是否是个好主意，这是有争议的。StyleCop 规则强制一行定义在单行上，或者每个元素都在单独的行上。我个人认为这是一个很好的指导方针，如果它太长而无法放入一个好的 80-90 个字符宽的编辑器中，我通常会选择将一行完全分解成它的部分。

---

---

Edit in response to your new question:

针对您的新问题进行编辑：

In this case, I would follow the guidelines above. Personally, in your specific case, I'd leave this on one line:

在这种情况下，我将遵循上述准则。就个人而言，在您的具体情况下，我会将其放在一行上：

SomeMethod(int someInt, Object someObject, String someString, bool someBool) 
{ 
    ... 
} 

This is a nice, short moethod declaration, and I see no reason to split it. I'd only split it if the number of arguments, and the lengths of the types, became far to long for one line of text.

这是一个很好的、简短的方法声明，我认为没有理由拆分它。如果参数的数量和类型的长度对于一行文本来说太长了，我只会拆分它。

If you do split it, however, I'd split it into separate lines for each argument:

但是，如果您确实将其拆分，我会将其拆分为每个参数的单独行：

SomeMethod(
    int someInt, 
    Object someObject, 
    String someString, 
    bool someBool) 
{ 
    ... 
} 

This way, at least it's obvious how and why it's split, and a developer won't accidentally skip one argument since two are on a single line.

这样，至少很明显它是如何以及为什么分开的，并且开发人员不会意外地跳过一个参数，因为两个参数在一行上。

回答by Aaronaught

Now that we've clarified that this isn't to do with actual line-continuation characters and simply line-wrapping - you tell me. This:

现在我们已经澄清，这与实际的续行字符和简单的换行无关 - 你告诉我。这个：

IEnumerable<int> orderIDs = context.Customers.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10).Select(c => c.Orders).SelectMany(o => o).OrderBy(o => o.OrderDate).Select(o => o.OrderID);

Or this?

或这个？

IEnumerable<int> orderIDs = context
    .Customers
    .Where(c => c.CustomerID >= 1 && c.CustomerID <= 10)
    .Select(c => c.Orders)
    .SelectMany(o => o)
    .OrderBy(o => o.OrderDate)
    .Select(o => o.OrderID);

Which would you rather read?

你更愿意读哪个？

回答by Kaleb Brasee

I think that the limit of line length has gradually been lengthening (or disappearing) over the past few years as everyone gets widescreen hi-res monitors and rarely print out code anymore. None of the projects I've worked on have an official guideline, we just use common sense and linebreak at roughly a editor window's width (everyone uses the same basic Eclipse window layout at about the same resolution). I see no problems with this method.

我认为在过去几年中，随着每个人都获得宽屏高分辨率显示器并且很少再打印代码，线路长度的限制逐渐延长（或消失）。我参与的所有项目都没有官方指南，我们只是在大约编辑器窗口的宽度上使用常识和换行符（每个人都使用相同的基本 Eclipse 窗口布局，分辨率大致相同）。我认为这种方法没有问题。

回答by Permaquid

I favour breaking lines at logical points. The reason is to help with source code control differencing and merging functions. I have found that understanding changes in such an environment is much easier if statements with many elements are broken onto multiple lines.

我喜欢在逻辑点断线。原因是帮助源代码控制差异和合并功能。我发现，如果将包含许多元素的语句分成多行，则更容易理解这种环境中的变化。

Monitors are large. But you can find youself working on a laptop computer and performing a merge in which you have base, source and target branches in separate windows across the screen. Count the characters: each of these windows on a 17-inch laptop is only about 55 characters wide.

显示器很大。但是您会发现自己在笔记本电脑上工作并执行合并，其中在屏幕上的不同窗口中具有基本分支、源分支和目标分支。数一下字符：17 英寸笔记本电脑上的每个窗口只有大约 55 个字符宽。

If you are working remotely you will discover that horizontal scrolling is not well optimized, and you may well think a few reproachful thoughts about programmers who write functions with 15 parameters on a single line.

如果您在远程工作，您会发现水平滚动没有得到很好的优化，并且您可能会想到一些关于程序员在一行中编写带有 15 个参数的函数的责备想法。

So think about ALL the ways you have to work on the source code, and break lines at places which serve ALL your needs.

因此，请考虑处理源代码的所有方式，并在满足您所有需求的地方换行。

回答by Kris Krause

Personally, I like to be able to "see" everything. Then again, I have a pretty decent monitor. But seriously, I like nice and small functions vs. gigantic functions with nested "if" statments. Same with a lines of code.

就个人而言，我喜欢能够“看到”一切。再说一次，我有一个相当不错的显示器。但说真的，我喜欢漂亮的小函数与带有嵌套“if”语句的巨大函数。与一行代码相同。

At the end of the day, it comes down to personal preference and whatever you and your team members decide. Be consistent. And favor readability for the next guy that looks at your code.

归根结底，这取决于个人喜好以及您和您的团队成员的决定。始终如一。并为下一个查看您的代码的人提供可读性。

回答by Diego Tercero

Some years ago I read Damian Conway's Perl Best Practices. Here's a link below

几年前，我阅读了 Damian Conway 的Perl Best Practices。这是下面的链接

Perl Best Pracices on Google Books

Google 图书上的 Perl 最佳实践

There's a whole chapter there dealing with Code Layout. All my feelings about code layout are summed up in his writing. I highly recommend that chapter. It can be easily applied to C#.

有一整章处理代码布局。我对代码布局的所有感受都在他的文章中得到了总结。我强烈推荐那一章。它可以很容易地应用于 C#。

I've been trying to stick to his rules for whatever language I might be using : C#, Java, Perl, JavaScript, VBScript, VB, PHP,...

对于我可能使用的任何语言，我一直试图遵守他的规则：C#、Java、Perl、JavaScript、VBScript、VB、PHP、...

In this book, Conway suggest to use 78-column lines. I've got to admit I broke the rule and sticked to 80 but I think it's OK.

在本书中，康威建议使用 78 列的行。我必须承认我违反了规则并坚持了 80，但我认为这没关系。

I've integrated this rule to every editor I use (Notepad++, Komodo, Vi, Vim, Visual Studio 2005) in order to have a visual guideline showing this limit.

我已将此规则集成到我使用的每个编辑器（Notepad++、Komodo、Vi、Vim、Visual Studio 2005）中，以便有一个显示此限制的视觉指南。

Some of you might wonder how to show a guideline on VS, huh?

你们中的一些人可能想知道如何在 VS 上显示指南，是吗？

Well I found it to be not so obvious. In fact, you have to actually create a string parameter in the registry. Here's a post I found on SO about it. Hope it helps.

嗯，我发现它不是那么明显。实际上，您必须在注册表中实际创建一个字符串参数。这是我在 SO 上找到的一篇关于它的帖子。希望能帮助到你。

Adding a guideline to the editor in Visual Studio

向 Visual Studio 中的编辑器添加指南