线宽的 C# 编码约定

标签 c# .net coding-style

<分区>

Possible Duplicate:
C# coding style - line length / wrapping lines

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

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

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

最佳答案

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

每个人都会有自己的看法,我个人认为现在 80 个字符的行宽在另一个方向有点偏离,但具体取决于它的内容,我尽量将自己控制在 100-120 个字符以下每行,包括缩进。如果它变得比这长得多,其中的部分可能很容易被分解并以提高可读性的方式放在单独的行中。

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

此外,尝试以提供有意义的差异的方式对代码进行分块,这些差异同样易于阅读。这是我努力坚持的另一条经验法则;如果我比较两组文件,我想看到真正重要的变化,而不是一公里长的行,唯一的区别是单个字符的变化(这很可能是一个非常有效的变化,但很难在这样的地方找到一个庞然大物)。

关于线宽的 C# 编码约定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5402799/

相关文章:

c# - 对于不同的 mscorlib 版本,无法将 IEnumerable<T> 转换为 IEnumerable<T>

c# - 调试二叉树

.net - 如何在 LINQPad 中使用 Akavache?

c# - ThreadAbortException(WebClient 使用 DownloadFile 从服务器获取文件)

c# - MVC3 : How to handle constructor exception in controller?

android - 检查方法中的 Android 权限

c - 以 OOP 风格处理图形

c# - 从独立存储中的图像设置辅助平铺背景图像

c# - 用于碰撞检测的边界框重叠并导致问题

.net - BackgroundWorker线程问题