我是一名应届AI毕业生（大约2年），工作不多。创建基本的C＃编码标准文档（主要是因为我是该部门的第一个“采用者”）已由我负责。
我想我应该解释一下，我可能是最初级的软件工程师，但是我很期待这个任务，因为我希望我可能能够生产出一半可用的东西。我已经对Internet进行了相当广泛的搜索，并阅读了有关编码标准文档应包含/不应包含的文章。这似乎是寻求任何建议的好地方。
我意识到，我有可能打开一个通往“最佳做事方式”异议世界的大门。我既理解又尊重一个不可否认的事实，即每个程序员都有解决每个任务的首选方法，因此，我并不是想写任何过于pro脚的命令来扼杀个人才能，而是尝试获得一种通用方法并达成共识标准（例如命名约定），以帮助使个人代码更具可读性。
所以这里....有什么建议吗？有没有
Answers:
我们从
然后记录与该基准的区别和补充。
IDesign具有一个常用的C＃编码标准文档。另请参阅《框架设计指南第二版》。
具有讽刺意味的是，设置实际标准可能很容易。
我的第一个建议是从其他工程师那里获得关于他们应该涵盖的内容以及他们认为重要的准则的建议。实施任何类型的指南都需要一定程度的人员支持。如果您突然在文档上放了一个文档，该文档指定了如何编写代码，则无论您是最初级的还是高级的，都会遇到阻力。
提出一组建议后，请将其发送给团队以征求反馈和审查。再一次，让人们全力以赴。
可能已经采用了非正式的编码实践（例如，为成员变量加上前缀，驼峰函数名称）。如果存在，并且大多数代码都遵循它，那么它将需要形式化其使用。即使通常建议这样做，采用相反的标准也会带来更多的痛苦。
还值得考虑重构现有代码以满足新的编码标准。这看起来像是在浪费时间，但是拥有不符合标准的代码可能会适得其反，因为您将遇到各种风格的混搭。人们是否在某个模块中的代码应该遵循新标准还是遵循现有代码风格方面也陷入了困境。
在内部进行编码标准/最佳实践时，我一直使用Juval Lowy的pdf作为参考。它非常接近FxCop / Source Analysis，这是确保遵循标准的另一个宝贵工具。在这些工具和参考之间，您应该能够提出一个好的标准，所有开发人员都不会介意并能够执行它们。
其他海报将您指向基线，我要补充的是使您的文档简短，甜美，并且要点，要使用大量的Strunk和White来区分“必备”和“如果有，那就更好了”。 ”。
编码标准文档的问题在于，没有人真正按照需要阅读它们，而当他们阅读它们时却没有遵循它们。读取和跟踪此类文档的可能性与其长度成反比。
我同意FxCop是一个很好的工具，但是过多使用它可能会使编程失去所有乐趣，因此请当心。
切勿使用MS（或适用于您的语言的Sun或...）编写自己的编码标准。线索在“标准”一词中，如果每个组织都没有决定自己编写代码，那么世界将更容易编码。谁真的认为每次您更改团队/项目/角色时学习一套新的“标准”都是对任何人的时间的良好利用。您应该做的最大的事情就是总结关键点，但我建议不要这样做，因为关键的内容因人而异。我想就编码标准提出另外两点
这两点是我希望每个人都编写看起来相同的代码的现实。
我会将“代码完成2”添加到列表中（我知道Jeff在这里很喜欢）...如果您是初级开发人员，这本书将很方便地树立您的思想，从而为最好的基础奠定基础有代码编写实践和软件构建。
我不得不说我在职业生涯中来得有点晚，但是它决定了我在职业生涯中对编码和框架开发的许多思考方式。
值得一试;）
我很想强制执行Microsoft的StyleCop作为标准。可以在构建时强制执行。但是，如果您有旧版代码，则只需对新代码强制使用StyleCop。
http://code.msdn.microsoft.com/sourceanalysis
最终它将有一个重构选项来清理代码。
我个人很喜欢IDesign组装的产品。但这不是我要发布的原因...
我公司的棘手问题是考虑了所有不同的语言。我知道我的公司并不孤单。我们使用C＃，C，程序集（我们制造设备），SQL，XAML等。尽管标准中会有一些相似之处，但每个标准通常都以不同的方式处理。
另外，我相信更高级别的标准对最终产品的质量会有更大的影响。例如：如何以及何时使用注释，何时强制使用异常（例如，用户启动的事件），是否（或何时）使用异常与返回值，确定控制器代码与表示代码应采用的客观方法是什么，等。不要误会我的意思，也需要低级标准（格式对于可读性很重要！）我只是对整体结构有偏见。
另一个需要牢记的是买进和执行。编码标准很棒。但是，如果没有人同意他们，并且（可能更重要的是）没有人强迫他们，那一切都是徒劳的。
当我撰写为飞利浦医疗系统公司出版的一本论文和在http://csharpguidelines.codeplex.com上的一本论文时，我可能有些偏颇，但我在编写，维护和推广编码标准方面已有十多年的经验。我试图编写一个CodePlex时考虑到了不同的观点，并且大部分介绍都花在了如何在您的特定组织中处理它。阅读并向我提供反馈.....
我最近找到了Encodo C＃手册，其中包含来自许多其他来源（IDesign，Philips，MSDN）的想法。
另一个来源可能是《专业C＃/ VB .NET编码指南》。
我是Francesco Balena一书的“ VB和C＃开发人员的实用指南和最佳实践 ”的忠实拥护者。
它非常详细，涵盖了所有基本主题。它不仅为您提供了规则，而且还解释了该规则背后的原因，甚至提供了可能存在两个相反最佳实践的反规则。唯一的缺点是它是为.NET 1.1开发人员编写的。
我必须建议dotnetspider.com文件。
这是一个非常详尽的文档，可在任何地方使用。
您可以查看此内容，C＃/。NET开发人员的前7个编码标准和指南文档http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html 希望这对您有所帮助
在我编写的代码中，我通常遵循面向公众的API的.NET Framework设计指南以及针对私有成员的大小写和缩进的Mono Coding指南。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提供帮助；-)
p_strName-当您被迫使用这种可憎的代码时，它的痛苦减轻了10％。：o