团队中的C#：代码风格与约定，拯救你的项目

为什么代码风格不是“我觉得好看就行”

你是否曾经打开过别人的C#代码，感觉自己像考古学家在挖掘古庙废墟？public int a;，var x = GetSmth() 毫无上下文，以及长达400行的方法。如果是这样——你就知道一个没有统一代码风格的团队有多让人头疼。

团队协作不仅仅是关于Git和代码审查。它还关乎你的代码会被其他人阅读。如果你是为自己写代码，那么C#代码风格就是无聊的官僚主义。但如果你是为团队写代码——那就是拯救神经、时间和生产环境的良方。

在本文中，我们将探讨哪些C#约定在2024年真正有效，如何无痛地引入它们，以及为什么EditorConfig是你最好的朋友。开始吧。

基本规则：首先需要达成共识的事项

1. 命名约定

C#有严格的标准，但团队经常违反它们。以下是90%的.NET团队接受的最低黄金标准：

\n
• PascalCase — 用于类、方法、属性、公共字段：public class UserService，public string GetUserName()。
\n
• camelCase — 用于局部变量、方法参数、私有字段（通常带前缀_）：private int _userId;，var userName = "Alex";。
\n
• 避免匈牙利命名法 — strName，intCount — 这是上个世纪的做法。变量类型应从上下文中显而易见。
\n
• 不要无谓地缩写 — GetUsrInf() 比 GetUserInformation() 更差。例外：通用缩写（IO，UI，DTO）。
\n

// 糟糕\npublic class user_service\n{\n    public int id;\n    public string nm;\n    private string _data;\n    public string GetData() => _data;\n}\n\n// 良好\npublic class UserService\n{\n    public int Id { get; }\n    public string Name { get; }\n    private readonly string _userData;\n\n    public string GetUserData() => _userData;\n}

2. 格式化：空格、括号、空行

关于在catch (Exception e)中冒号前是否加空格的争论永无止境。因此，请使用自动化工具。但基本的约定仍然是必要的：

\n
• 缩进 — 4个空格（C#中很少使用制表符，但如果团队选择了制表符，也没问题）。
\n
• 花括号 — 始终在新行上（Allman风格）。这是C#的标准。
\n
• 方法之间留一个空行。类之间留两个空行。
\n

// 糟糕（花括号在同一行——这是Java，不是C#）\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// 良好（Allman风格）\npublic void Process()\n{\n    var result = Calculate();\n    return result;\n}

高级约定：最常见的绊脚石

3. 使用var

这是永恒的争论之一。规则很简单：当类型从右侧显而易见时，使用var。如果不是，则显式写出类型。

// 可以用var\nvar users = GetUsers(); // 类型显而易见\nvar dictionary = new Dictionary<string, int>(); // 长声明\n\n// 最好显式写出\nUser user = GetUserById(id); // 不清楚返回的是User\nDictionary<string, int> result = ParseData(); // 也不清楚

如果你的团队不喜欢var——只需达成一致。关键是保持一致性。

4. 使用LINQ

LINQ是一个强大但阴险的工具。常见的错误是链式调用长达10个方法，读起来像咒语。请约定：

\n
• 将长的LINQ表达式拆分为多行。
\n
• 不要滥用.Select()，当需要的是pr