c# - 对于开发 C# 编码标准/最佳实践文档有什么建议吗？

Question

我是一名刚毕业的 AI 毕业生（大约 2 年），正在为一个适度的操作工作。我（主要是因为我是该部门的第一个“采用者”）创建了一个基本的（读起来有用吗？）C# 编码标准文档。

我想我应该解释一下，我可能是最初级的软件工程师，但我很期待这项任务，因为希望我实际上能够生产出一半可用的东西。我在 Internet 上进行了相当广泛的搜索，并阅读了有关编码标准文档应该/不应该包含什么的文章。这似乎是一个很好的地方，可以征求一些建议。

我意识到我可能会打开一扇通往全世界关于“最好的做事方式”的分歧的大门。我理解并尊重一个不可否认的事实，即每个程序员都有解决每个单独任务的首选方法，因此我不想写任何如此严厉的禁止性来扼杀个人天赋，而是试图获得一个通用的方法并同意标准（例如命名约定），以帮助使个人代码更具可读性。

所以这里......有什么建议吗？有吗？

score 139 · Accepted Answer

我们从

Microsoft 的 .NET 指南： http: //msdn.microsoft.com/en-us/library/ms229042.aspx（针对 .NET 4.5 更新的链接）
Microsoft 的 C# 指南：http: //blogs.msdn.com/brada/articles/361363.aspx。

然后记录与该基线的差异和添加。

score 32 · Accepted Answer

32

IDesign有一个常用的 C# 编码标准文档。另请参阅框架设计指南第 2 版。

于 2008-08-18T17:45:39.430 回答

score 26 · Accepted Answer

具有讽刺意味的是，设定实际标准可能是容易的部分。

我的第一个建议是征求其他工程师关于他们认为应该涵盖哪些内容以及他们认为重要的指导方针的建议。执行任何类型的指导方针都需要人们一定程度的支持。如果您突然将一份说明如何编写代码的文档放在他们身上，无论您是资历最深的人还是资历最深的人，您都会遇到阻力。

在您有一组提案后，然后将它们发送给团队以进行反馈和审查。再次，让人们都购买它们。

可能已经采用了非正式的编码实践（例如，为成员变量添加前缀、驼峰式函数名称）。如果这存在，并且大多数代码都符合它，那么将它的使用形式化是值得的。采用相反的标准会导致更多的悲伤而不是它的价值，即使它是普遍推荐的。

还值得考虑重构现有代码以满足新的编码标准。这似乎是在浪费时间，但如果代码不符合标准，可能会适得其反，因为您将拥有不同风格的混搭。这也让人们在某个模块中的代码是应该遵循新标准还是遵循现有的代码风格时陷入两难境地。

score 14 · Accepted Answer

在内部进行编码标准/最佳实践时，我一直使用 Juval Lowy 的pdf作为参考。它与FxCop / Source Analysis非常接近，后者是确保遵循标准的另一个宝贵工具。在这些工具和参考之间，您应该能够提出一个很好的标准，您的所有开发人员都不会介意遵循并能够强制执行它们。

score 9 · Accepted Answer

其他海报已将您指向基线，我要添加的只是使您的文档简短，甜美，并且重点突出，使用大量的 Strunk 和 White 来区分“必备品”和“如果”。

编码标准文档的问题在于，没有人真正按照他们应该的方式阅读它们，而且当他们阅读它们时，他们并没有遵循它们。此类文档被阅读和遵循的可能性与其长度成反比。

我同意 FxCop 是一个很好的工具，但是太多的东西会带走编程的所有乐趣，所以要小心。

score 9 · Accepted Answer

永远不要编写自己的编码标准，使用 MS 标准（或 Sun 标准或……根据您的语言而定）。线索就在标准这个词中，如果每个组织都没有决定编写自己的代码，世界将是一个更容易编写代码的地方。谁真的认为每次你改变团队/项目/角色时学习一套新的“标准”是对任何人时间的一种很好的利用。您应该做的最多的是总结关键点，但我建议您不要这样做，因为关键因人而异。我想就编码标准提出另外两点

接近就足够了 - 只要代码足够接近，更改代码以遵循编码标准就是浪费时间。
如果您要更改您没有编写的代码，请遵循“本地编码标准”，即让您的新代码看起来像周围的代码。

这两点是我希望每个人都编写看起来相同的代码的现实。

score 8 · Accepted Answer

我发现以下文档非常有用且简洁。它来自 idesign.net 网站，由 Juval Lowy 撰写

C# 编码标准

注意：上面的链接现在已经失效了。要获取 .zip 文件，您需要向他们提供您的电子邮件地址（但他们不会将其用于营销......老实说）试试这里

score 5 · Accepted Answer

我会将Code Complete 2添加到列表中（我知道 Jeff 是这里的粉丝）...如果您是初级开发人员，这本书会派上用场，以一种为最好的方式奠定基础的方式来设置您的想法有代码编写实践和软件构建。

我不得不说我在职业生涯中有点晚了，但它支配了我在职业生涯中思考编码和框架开发的许多方式。

值得一试；）

score 5 · Accepted Answer

我刚刚开始在编码标准要求使用 m_ 表示成员变量、p_ 表示参数和类型前缀的地方，例如字符串的“str”。所以，你可能在方法体中有这样的东西：

m_strName = p_strName;

可怕。真的很可怕。

score 4 · Accepted Answer

4

微软自己的规则是一个很好的起点。您可以使用 FxCop 强制执行它们。

于 2008-08-18T17:41:00.530 回答

score 4 · Accepted Answer

我很想强制执行 Microsoft 的 StyleCop 作为标准。它可以在构建时强制执行。但如果你有遗留代码，那么只需在新代码上强制使用 StyleCop。

http://code.msdn.microsoft.com/sourceanalysis

最终它将有一个重构选项来清理代码。

http://blogs.msdn.com/sourceanalysis/

score 4 · Accepted Answer

就我个人而言，我喜欢IDesign整合的那个。但这不是我发帖的原因...

我公司的棘手问题是考虑到所有不同的语言。我知道我的公司并不孤单。我们使用 C#、C、程序集（我们制作设备）、SQL、XAML 等。虽然标准中会有一些相似之处，但通常处理方式不同。

另外，我相信更高级别的标准对最终产品的质量有更大的影响。例如：如何以及何时使用注释，何时强制异常（例如用户发起的事件），是否（或何时）使用异常与返回值，确定控制器代码与表示代码的客观方法是什么，等等不要误会我的意思，还需要低级标准（格式对可读性很重要！）我只是对整体结构有偏见。

要记住的另一件事是买入和执行。编码标准很棒。但是，如果没有人同意它们并且（可能更重要的是）没有人强制执行它们，那么这一切都是徒劳的。

score 4 · Accepted Answer

当我为 Philips Medical Systems 和http://csharpguidelines.codeplex.com撰写的那篇文章时，我可能有点偏颇，但我在编写、维护和推广编码标准方面有 10 多年的时间。我试图编写一个具有不同意见的 CodePlex，并将大部分介绍用于如何在您的特定组织中处理该问题。阅读它并向我提供反馈......

score 2 · Accepted Answer

2

SSW 规则

它包括一些 C# 标准 + 更多……主要针对 Microsoft 开发人员

于 2012-02-11T10:51:51.727 回答

score 1 · Accepted Answer

你很可能会失败。欢迎加入行业。

我不同意——只要他创建了文件，可能发生的最糟糕的情况就是它被所有人遗忘。

如果其他人对内容有疑问，那么您可以要求他们更新内容以显示他们更喜欢的内容。这样一来，你就不用管了，其他人有责任证明他们的改变是合理的。

score 1 · Accepted Answer

我最近发现了 Encodo C# Handbook，其中包含来自许多其他来源（IDesign、Philips、MSDN）的想法。

另一个来源可能是Professional C#/VB .NET Coding Guidelines。

score 1 · Accepted Answer

我是 Francesco Balena 的书“面向 VB 和 C# 开发人员的实用指南和最佳实践”的忠实粉丝。

它非常详细，涵盖了所有基本主题，它不仅为您提供规则，还解释了规则背后的原因，甚至提供了可能存在两种相反最佳实践的反规则。唯一的缺点是它是为 .NET 1.1 开发人员编写的。

score 1 · Accepted Answer

请参阅： http ://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx 。

score 1 · Accepted Answer

1

我们的整个编码标准大致读作“使用 StyleCop”。

于 2009-07-29T13:07:00.407 回答

score 1 · Accepted Answer

我必须建议dotnetspider.com文档。
这是一个伟大而详细的文档，在任何地方都很有用。

score 1 · Accepted Answer

我以前用过 Juval 的，如果不是矫枉过正的话，那就是通过了，但我很懒，现在只符合Resharper的意愿。

score 1 · Accepted Answer

您可以查看此，C#/.NET 开发人员的 7 大编码标准和指南文档http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html 希望对您有所帮助

score 0 · Accepted Answer

我想我在这里回应其他评论，已经链接的 MS 指南是一个很好的起点。我主要基于这些来建模我的代码。

这很有趣，因为我的经理过去曾告诉我他不太喜欢他们：D

你有一个有趣的任务摆在你面前，我的朋友。祝你好运，请询问您是否需要更多:)

score 0 · Accepted Answer

飞利浦医疗系统的标准写得很好，主要遵循微软的指导方针：www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

我的标准在此基础上进行了一些调整，并对 .NET 2.0 进行了一些更新（飞利浦标准是为 .NET 1.x 编写的，所以有点过时了）。

score 0 · Accepted Answer

我也关注 Resharper。还有 scott guthrie 博客http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net上提到的指南 .aspx 和 http://csharpguidelines.codeplex.com/releases/view/46280

score 0 · Accepted Answer

在我编写的代码中，我通常遵循针对公开 API 的.NET Framework 设计指南和针对私有成员大小写和缩进的Mono 编码指南。Mono 是 .NET 的开源实现，我认为这些人知道他们的业务。

我讨厌 Microsoft 代码如何浪费空间：

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

在 Mono 指南中，您可能会觉得奇怪的是它们使用 8 个空格的制表符。然而，经过一些练习，我发现它实际上通过强制一种缩进限制来帮助我编写更少纠结的代码。

我也喜欢他们在开括号之前放置空格的方式。

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

但是，如果您的同事不喜欢它，请不要强制执行类似的操作（除非您愿意为 Mono 做出贡献；-）

c# - 对于开发 C# 编码标准/最佳实践文档有什么建议吗？

26 回答 26

Related

Reference