是否有任何关于开发 C # 编码标准/最佳实践文档的建议？

我是一个刚毕业的人工智能研究生(大约2年) ，在一家中等规模的公司工作。我(主要是因为我是这个部门的第一个“采用者”)负责创建一个基本的(阅读有用吗?)C # 编码标准文档。

我认为我应该解释，我可能是最初级的软件工程师去，但我期待着这项任务，因为希望我可能实际上能够产生一半可用的东西。我在互联网上做了一个相当广泛的搜索，并阅读了一些关于编码标准文档应该或不应该包含什么内容的文章。这似乎是一个征求意见的好地方。

我意识到，我可能会打开一扇门，让整个世界对“做事情的最佳方式”产生分歧。我理解并且尊重这样一个不可否认的事实: 每个程序员都有解决每个单独任务的首选方法，因此，我并不打算写一些严格禁止的东西来扼杀个人才能，而是尝试获得一个通用的方法和公认的标准(例如命名约定)来帮助个人代码更具可读性。

那么，有什么建议吗? 任何建议？

72318 次浏览
小开

微软自己的规则是一个很好的起点，你可以用 FxCop 来执行它们。

小开
最佳答案

我们从

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

小开

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

小开

IDesign 有一个常用的 C # 编码标准文档。

小开

其他的海报已经把你指向了基准线，我要补充的就是让你的文档简短、甜美，并且切中要点，使用大剂量的 Strunk 和 White 来区分“必须有”和“如果有就好了”。

编写标准文档的问题在于，没有人真正像他们应该的那样阅读标准文档，当他们真正阅读标准文档时，他们并没有遵循标准文档。这种文件被阅读和跟踪的可能性与其长度成反比。

我同意 FxCop 是一个很好的工具，但是太多这样的工具会让编程失去所有的乐趣，所以要小心。

小开

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

我的第一个建议是从其他工程师那里获得建议，他们认为应该涵盖哪些内容，以及哪些指导方针是重要的。执行任何类型的指导方针都需要人们在一定程度上的支持。如果你突然扔给他们一个文件，指定如何编写代码，你会遇到阻力，无论你是最初级或高级的家伙。

在你有了一系列的建议之后，把它们发送给团队以获得反馈和评审。再说一次，让人们都相信他们。

可能已经采用了非正式的编码实践(例如，前缀成员变量、驼峰函数名)。如果存在这种情况，并且大多数代码都符合这种情况，那么将它的使用形式化是值得的。采取一个相反的标准将会导致比它的价值更多的悲伤，即使它是普遍推荐的东西。

为了满足新的编码标准，重构现有代码也是值得考虑的。这可能看起来像是浪费时间，但是拥有不符合标准的代码可能会适得其反，因为您将拥有各种不同风格的混杂。这也使得人们在某个模块中的代码是否应该遵循新的标准或遵循现有的代码风格的问题上左右为难。

小开

我想我赞同这里的其他评论，即已经链接的 MS 指南是一个很好的起点。我的代码很大程度上是基于这些内容建模的。

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

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

小开

你很可能是被设计成失败的，欢迎来到这个行业。

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

如果其他人对内容有问题，那么你可以要求他们更新内容，以显示他们更喜欢什么。这样就不用你操心了，其他人也有责任证明他们的改变是正确的。

小开

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

  1. 接近就足够了——只要代码足够接近，改变代码以完全遵循编码标准就是浪费时间。
  2. 如果你正在修改你没有写的代码，遵循“本地编码标准”，也就是说，让你的新代码看起来像周围的代码。

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

小开

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

我的标准是以此为基础的，并进行了一些调整和更新。NET 2.0(飞利浦标准是为。NET 1.x 所以有点过时了)。

小开

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

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

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

Http://blogs.msdn.com/sourceanalysis/

小开

我想把 代码完成2添加到这个列表中(我知道 Jeff 是这里的一个粉丝) ... ... 如果你是一个初级开发人员，这本书可以帮助你建立思维，为最好的代码编写实践和软件构建奠定基础。

我不得不说，在我的职业生涯中，我来到这个领域有点晚，但是在我的职业生涯中，它规定了我思考编码和框架开发的许多方式。

值得一试;)

小开

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

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

小开

我发现下面的文档非常有用和简洁。它来自 idesign.net 网站，作者是 Juval Lowy

C # 编码标准

注意: 上面的链接现在已经死亡。为了得到。压缩文件，你需要给他们你的电子邮件地址(但他们不会使用它的营销... 老实说)尝试 给你

小开

我是 Francesco Balena 的书《 VB 和 C # 开发者的实用指南和最佳实践》的忠实粉丝。

它非常详细，涵盖了所有重要的主题，它不仅给你规则，还解释了规则背后的原因，甚至提供了一个反规则，可能有两个对立的最佳实践。唯一的缺点就是。NET 1.1开发人员。

小开

看这个: Http://www.noesispedia.com/post/2008/11/28/c-coding-guidelines-and-best-practices.aspx.

小开

我刚刚开始编码标准要求对成员变量使用 m _，对参数使用 p _，对类型使用前缀，比如对字符串使用‘ str’。 所以，你可能在方法的主体中有类似这样的东西:

M _ strName = p _ strName;

太可怕了，真的太可怕了。

小开

就个人而言，我喜欢 IDesign放在一起的一个。但这不是我为什么张贴..。

我们公司最棘手的地方就是把所有不同的语言都考虑进去。我知道我的公司并不是孤军奋战。我们使用 C # 、 C、汇编(我们制造设备)、 SQL、 XAML 等。尽管在标准方面会有一些相似之处，但是每个标准通常都有不同的处理方式。

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

另一个需要记住的是买入和执行。编码标准很好。但是，如果没有人同意他们，(可能更重要的是)没有人执行他们，那么这一切都是徒劳的。

小开

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

小开

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

小开

我以前用过尤文的球衣，如果不是太过分的话，那也是通过的，但是我很懒，现在只是遵循 清醒一下的意志。

小开

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

小开

在我编写的代码中，我通常遵循 < a href = “ http://msdn.microsoft.com/en-us/library/ms229042.aspx”rel = “ nofollow”> < a href = “ http://msdn.microsoft.com/en-us/library/ms229042.aspx”rel = “ nofollow”> 。NET 框架设计指南针对公开的 API，以及针对私有成员外壳和缩进的 Mono 编码指南。Mono 是一个开源实现。我想那些家伙知道他们的业务。

我讨厌微软的代码如何浪费空间:

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 #/. NET 开发人员的7大编码标准和指导文档 http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html希望这有所帮助

小开

当我为飞利浦医疗系统公司和 http://csharpguidelines.codeplex.com公司出版的文章时，我可能会有一点偏见，但是我在编写、维护和推广编码标准方面已经有10多年的经验了。我曾经尝试写过一个有着不同观点的 CodePlex，并且用了大部分的介绍来阐述如何在你的特定组织中处理这个问题。阅读它，并提供反馈给我... ..。

小开

社会福利署规则

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


提交答案