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

https://stackoverflow.com/questions/14967

08-06-2019
|

题

我是一名刚毕业的人工智能专业毕业生（大约两年），在一家规模不大的公司工作。创建一个基本的（读起来有用吗？）C# 编码标准文档的任务落在了我身上（主要是因为我是该部门的第一个“采用者”）。

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

我意识到我可能会为关于“最好的做事方式”的整个世界的分歧打开一扇大门。我既理解也尊重不可否认的事实，即每个程序员都有解决每个单独任务的首选方法，因此我不希望编写任何如此严格的规定来扼杀个人才能，而是尝试获得通用的方法并达成一致标准（例如命名约定）以帮助使个人代码更具可读性。

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

解决方案

我们从

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

然后记录与该基线的差异和补充。

其他提示

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

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

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

获得一组提案后，请将其发送给团队以供反馈和审核。再次，让人们都相信它们。

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

还值得考虑重构现有代码以满足新的编码标准。这看起来像是浪费时间，但拥有不符合标准的代码可能会适得其反，因为您将得到不同风格的大杂烩。这也让人们陷入了一个两难的境地：某个模块中的代码是应该符合新的标准，还是遵循现有的代码风格。

我一直用 Juval Lowy's pdf 作为内部制定编码标准/最佳实践时的参考。它非常接近福克斯警察/来源分析, ，这是确保遵循标准的另一个宝贵工具。在这些工具和参考资料之间，您应该能够提出一个很好的标准，所有开发人员都不会介意遵循并能够执行它们。

其他发帖者已经向你指出了基线，我要补充的是让你的文档简短、甜蜜、切中要害，使用大量的斯特伦克和怀特来区分“必须有”和“如果有的话那就太好了” ”。

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

我同意 FxCop 是一个很好的工具，但太多可能会剥夺编程的所有乐趣，所以要小心。

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

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

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

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

C# 编码标准

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

我刚刚开始，编码标准要求使用 m_ 表示成员变量，使用 p_ 表示参数，使用前缀表示类型，例如使用“str”表示字符串。因此，方法体内可能有这样的内容：

m_strName = p_strName;

可怕。真的太可怕了。

我想补充一下代码完成 2 到列表中（我知道杰夫是这里的粉丝）......如果您是一名初级开发人员，这本书可以派上用场，帮助您树立思想，为最佳代码编写实践和软件构建奠定基础。

我不得不说，我在职业生涯中接触它的时间有点晚，但它决定了我在职业生涯中思考编码和框架开发的很多方式。

值得一看;)

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

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

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

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

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

就我个人而言，我喜欢这样的一个设计已经放在一起了。但这不是我发帖的原因...

我公司的棘手之处在于考虑所有不同的语言。我知道我的公司并不是唯一一家这样做的公司。我们使用 C#、C、汇编（我们制造设备）、SQL、XAML 等。尽管标准之间存在一些相似之处，但每个标准的处理方式通常有所不同。

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

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

正如我所写的，为飞利浦医疗系统发布的一篇和在 http://csharpguidelines.codeplex.com 我可能有点偏见，但我在编写、维护和推广编码标准方面有超过 10 年的经验。我尝试编写一个考虑到不同意见的 CodePlex，并在介绍中花费了大部分时间来讨论如何在您的特定组织中处理这一问题。阅读并给我反馈......

SSW规则

它包括一些 C# 标准以及更多......主要针对微软开发者

你很可能注定会失败。欢迎来到这个行业。

我不同意 - 只要他创建了该文档，最糟糕的情况就是它被每个人都忘记了。

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

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

另一个来源可能是专业 C#/VB .NET 编码指南.

我是弗朗西斯科·巴莱纳（Francesco Balena）这本书的超级粉丝”VB 和 C# 开发人员的实用指南和最佳实践".

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

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

看看这个：http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

我必须建议点网蜘蛛网文档。
这是一份很棒且详细的文档，在任何地方都很有用。

我以前用过Juval的，即使不是过度杀伤力，那也是通过的，但我很懒，现在只是顺应别人的意愿雷夏珀.

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

我想我同意这里的其他评论，即已经链接的 MS 指南是一个很好的起点。我的代码主要基于这些模型。

这很有趣，因为我的经理过去告诉我他不太热衷于它们：D

我的朋友，你面前有一项有趣的任务。祝你好运，如果你还需要什么，请询问:)

飞利浦医疗系统公司的标准写得很好，并且大部分遵循 Microsoft 指南：www.tiobe.com/content/paperinfo/gemrcsharps.pdf

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

我也关注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

在我写的代码中我通常遵循 .NET框架设计指南对于公开暴露的 API 和单色编码指南用于私人成员大小写和缩进. 。Mono 是 .NET 的开源实现，我认为这些人了解他们的业务。

我讨厌微软代码浪费空间的方式：

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 做出贡献；-）

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow