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