线宽的C#编码约定[重复]答案

【问题标题】：C# coding convention for line width [duplicate]线宽的C#编码约定[重复]
【发布时间】：2011-03-23 08:58:06
【问题描述】：

可能重复：
C# coding style - line length / wrapping lines

是否有广泛接受的 C# 编码约定，是否有建议的最大线宽？

每行 80 个字符的规则很常见，但我认为对于带有泛型的 C# 来说它有点太短了。那么 C# 还有其他约定吗？

解决方案：我的团队和我决定每行 100 个字符，这似乎是一个不错的行宽。

【问题讨论】：

你可以找到this Helpful
适合您屏幕的内容效果很好。如果您需要换行多行，则将其格式化以使其易于阅读。如果您需要在一行上放置更多内容，请选择较小的字体。就我个人而言，我宁愿线条从末端延伸而不是太短 - 出于某种让我感到烦恼的原因。
using ShorthandName = System.Collections.Generic.List<System.Collections.Generic.Dictionary<MyCompany.MyApplication.MyType, SomeOtherCompany.SomeOtherLibrary.SomeOtherType>>;

标签： c# .net coding-style

【解决方案1】：

如果我选择“适合什么”，除此之外没有太多想法，我会以每行 260 个字符将 60 行塞进一个函数中，并且仍然可以争辩说“它都适合我的屏幕”。确实如此，而且我也没有使用可笑的小字体。（9 pt Courier New，1920x1200 的 24 英寸宽屏显示器，基本上整个屏幕空间都用于代码；解决方案资源管理器、代码定义窗口、输出窗口、错误列表等在我的第二台显示器上。）

每个人都会有自己的看法，我个人认为现在 80 个字符的线宽在另一个方向上有点偏离，但根据具体情况，我尽量保持在 100-120 个字符以下每行，包括缩进。如果它比这长得多，那么其中的某些部分可能很容易被分解并放在单独的行中以提高可读性。

因为这才是真正的意义所在。 可读性。我真的不在乎你是每行使用 60 个字符还是 200 个字符，但是当我必须使用你的代码时，最好是易于阅读并且一眼就能看出是什么确实如此。

另外，尝试以能够提供有意义的差异且易于阅读的方式对代码进行分块。这是我试图坚持的另一个经验法则。如果我比较两组文件，我想查看真正重要的更改，而不是千米长的行，其中唯一的区别是单个字符更改（这很可能是一个非常有效的更改，但很难在这样的一个庞然大物）。

【讨论】：

【解决方案2】：

我尝试确保某个功能适合我的屏幕，而无需任何滚动（垂直或水平）。当然，每个人都有不同大小的显示器，以不同的分辨率运行，并且他们的工具栏/解决方案视图/输出窗口等的布局也不同，因此很难保证团队系统中的每个人都能做到这一点。这仍然是一个有用的指南。

【讨论】：

“确保功能适合我的屏幕，无需任何滚动（垂直或水平）” - 水平 - 很好，我也可以。但垂直？我什至无法想象。但我喜欢你的想法，所以 +1
这是分解方法的指南。如果它变得很长，将一些内容提取到另一个适当命名的函数中，因此原始方法是由对完成工作的方法的调用组成的，通过查看它的方法的名称可以清楚地理解它的作用来电。
对我来说听起来非常好。我非常希望它能够以这种方式编写代码。

【解决方案3】：

我有两台显示器，一台是 26 英寸，另一台是 22 英寸。我使用较小的一个来放置实用程序窗口，如文件结构、类视图、代码定义、对象浏览器、待办事项资源管理器、输出、错误列表、待更改（Ankh 插件）等。我只留下代码和项目浏览器的主窗口，所以我告诉 ReSharper 将我的行宽设置为 160 个字符（以防万一我需要一些行那么长）。通常我不会超过 120 个字符，这是我觉得最舒服的长度。如果我不得不在这台显示器上工作，我会感到非常愚蠢。

每行 80 个字符在过去是有意义的，当时它是文本模式下显示器的标准宽度。

【讨论】：

【解决方案4】：

我会选择合适的。我通常尽量不要从我正在处理的屏幕上延伸太远。有时，通过将语句放在多行中人为地缩小语句的范围并不比单行更长。

这是一个非常主观的问题！

【讨论】：