Question

我是最近的AI毕业生（大约2年），从事适度的操作。它已经落到我身上（主要是因为我是该部门的第一个'采用者'）来创建一个基本的（阅读有用的？）C＃编码标准文档。

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

我意识到我可能会打开一扇关于“最好的做事方式”的分歧的大门。我既理解又尊重不可否认的事实，即每个程序员都有一个解决每个任务的首选方法，因此我不打算写任何如此严厉的禁止，以至于扼杀个人风格，而是试图获得一般方法并达成一致标准（例如命名约定），以帮助使个人代码更具可读性。

所以这里......任何建议？什么都没有？

Answer 1

我们从

开始

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

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

Answer 2

IDesign有一个常用的C＃编码标准文档。另请参阅Framework Design Guidelines 2nd Ed。

Answer 3

讽刺的是，设定实际标准可能很容易。

我的第一个建议是引出其他工程师关于他们认为应该涵盖的内容的建议，以及他们认为重要的指导方针。执行任何类型的指导都需要人们的一定程度的支持。如果你突然放下一个指定如何编写代码的文档，你会遇到阻力，无论你是最初级的还是高级的。

在您有一组提案后，将其发送给团队以获得反馈和审核。再次，让所有人都购买它们。

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

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

Answer 4

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

Answer 5

其他海报已经指出你的基线，所有我想补充的是让你的文件简短，甜美，并且到了这一步，使用大剂量的Strunk和White来区分“必须有”和“它会”好的ifs“。

编码标准文档的问题在于没有人真正按照他们的意愿阅读它们，当他们阅读它们时，他们不会遵循它们。 阅读和遵循此类文档的可能性与其长度成反比。

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

Answer 6

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

关闭已经足够了 - 只要代码足够接近，更改代码以遵循编码标准就会浪费时间。
如果您要更改代码，则不要按照“本地编码标准”进行编写，即使新代码看起来像周围的代码。

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

Answer 7

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

C# Coding Standard

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

Answer 8

我会在列表中添加Code Complete 2（我知道杰夫在这里是一个粉丝）...如果你是一名初级开发人员，那么这本书就可以用来设置你的思维方式有最好的代码编写实践和软件构建的基础。

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

值得一试;）

Answer 9

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

m_strName = p_strName;

可怕。太可怕了。

Answer 10

正如我为飞利浦医疗系统和http://csharpguidelines.codeplex.com发表的那篇文章所写，我可能有点偏颇，但我有超过10年的编写，维护和推广编码标准。我曾尝试编写一个CodePlex，其中包含了不同的意见，并在大多数介绍中介绍了如何在您的特定组织中处理这些问题。阅读它并向我提供反馈......

Answer 11

我个人喜欢IDesign放在一起的那个。但这不是我发帖的原因......

我公司的棘手问题是考虑了所有不同的语言。我知道我的公司并不孤单。我们使用C＃，C，汇编（我们制作设备），SQL，XAML等。虽然标准中会有一些相似之处，但每种方法通常都有不同的处理方式。

此外，我认为更高级别的标准对最终产品的质量有更大的影响。例如：如何以及何时使用注释，当例外是强制性的（例如用户启动的事件）时，是否（或何时）使用异常与返回值，确定控制器代码与表示代码的对比方式是什么，不要误解我的意思，还需要低级标准（格式化对可读性很重要！）我只是偏向于整体结构。

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

Answer 12

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

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

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

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

Answer 13

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

Answer 14

SSW Rules

它包括一些C＃标准+更多......主要针对微软开发人员

Answer 15

我是Francesco Balena书“Practical Guidelines and Best Practices for VB and C# Developers”的忠实粉丝。

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

Answer 16

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

Answer 17

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

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

Answer 18

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

Answer 19

我必须建议dotnetspider.com文件这是一本非常有用的详细文档。

Answer 20

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

Answer 21

你可以查看一下，Top 7 Coding Standards＆amp; C＃/。NET开发人员的指南文档http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html希望这有帮助

Answer 22

您最有可能被设置为失败。欢迎来到这个行业。

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

如果其他人对内容有疑问，那么您可以要求他们更新内容以显示他们更喜欢的内容。这样，它就会脱离你的盘子，其他人有责任证明他们的改变。

Answer 23

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

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

Answer 24

我也跟着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

Answer 25

在我编写的代码中，我通常会将 .NET Framework Design Guidelines用于公开公开的API，并Mono Coding Guidelines用于私有成员大小写和缩进。 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做出贡献; - ）

Answer 26

我想我在这里回应其他评论，已经链接的MS指导是一个很好的起点。我在很大程度上模拟了我的代码。

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

你的朋友面前有一项有趣的任务。祝你好运，如果您还需要更多信息，请询问：）

有没有关于开发C＃编码标准/最佳实践文档的建议？

26 个答案: