C# 编码风格 - 行长/换行 [关闭]答案

【问题标题】：C# coding style - line length / wrapping lines [closed]C# 编码风格 - 行长/换行 [关闭]
【发布时间】：2023-03-06 19:11:01
【问题描述】：

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

是否有普遍接受的使用换行符的礼仪？

为什么要使用这个：

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

而不是这个：

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

编辑：将我的问题从续行改为换行

【问题讨论】：

您的意思是仅仅将语句分散到多行，还是像 VB 中的下划线这样的实际延续字符？
我觉得这个问题很主观，就像问你喜欢红色吗？这完全取决于您的意见。
同意Postman，应该加上主观标签。没有一个正确答案，每个人都有自己的看法。
可惜每个人都不能有我的意见，哦，如果没有红色，世界会更美好！

标签： c# coding-style

【解决方案1】：

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

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

编辑以回答您的新问题：

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

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

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

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

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

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

【讨论】：

同意；我也是一个简明扼要的书呆子。我无法忍受自动换行。
我们的大脑工作方式很有趣——我真的会为这样的事情感到痛苦！
+1 我绝对同意拆分所有参数或不拆分。不一致只会使它更加混乱。
我同意这个答案，但有一个例外。我相信今天 120 个字符在上下文需要时是可以接受的行长。但是，如果行数为 80-90 或更少，我会说“做得好”。
@Wilmoore：我同意，除非您的团队有人在笔记本电脑上工作 - VS，尤其是在笔记本电脑上，具有合理大小的字体和打开的解决方案资源管理器，通常几乎不会达到 80 个字符的宽度......

【解决方案2】：

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

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

还是这个？

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

你更想读哪个？

【讨论】：

这是一个反问。 ;)
@Kevin：这是一个反问......
不换行。那是完全清晰的;)
@Mark - 当然，在 7680x1200 显示器上清晰易读！

【解决方案3】：

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

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

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

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

【讨论】：

非常好的点。我可以看到拆分行和使用 WinMerge 轻松识别更改的好处。

【解决方案4】：

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

【讨论】：

窗口宽度。 VS2K10 将具有浮动窗口（MDI 返回！），因此您可以将它们浮动到源窗口之外。我猜 VB 做对了。
@No Refunds No Returns：似乎 VS 每隔一个版本就会放弃 MDI，然后由于客户压力（我猜）而重新放回。我肯定更喜欢 MDI 编辑窗口，所有工具窗口都浮动在我的第二台显示器上。

【解决方案5】：

几年前，我阅读了 Damian Conway 的 Perl 最佳实践。这是下面的链接

Perl Best Pracices on Google Books

那里有一整章涉及代码布局。我对代码布局的所有感受都总结在他的写作中。我强烈推荐那一章。它可以很容易地应用于 C#。

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

在本书中，康威建议使用 78 列的行。我不得不承认我打破了规则并坚持到了 80，但我认为这没关系。

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

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

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

Adding a guideline to the editor in Visual Studio

【讨论】：

【解决方案6】：

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

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

【讨论】：