C编程标准中应该包括什么?

你有没有建议每个人都读 Design Guidelines for Class Library Developers “?占了大部分。除此之外,我还想敲响警钟:

• 您应该很少创建自己的结构。不要认为它们是轻量级的类。
• 结构不应该是可变的。
• 字段应始终是私有的,除了字段类型不可变的只读字段
• 只有当你确信一个简单的解决方案会太慢的时候才尝试无锁编程-并且有证据!
• 可读性是王道
• 注意文化问题-特别是阅读微软的 String Handling Recommendations

当我想到他们的时候,我会补充更多…

有关如何处理命名空间、程序集/项目/解决方案命名约定、文件命名约定的信息。项目分组(例如,项目和项目都在同一个文件中吗?)

• 文件名准则
• 名称空间命名/组织准则
• 设计和架构指导原则,如使用接口创建louse coupling和进行unittesting eaiser(例如依赖注入和模拟)
• 关于何时应该重构的建议(长方法等)
• 参数的命名和大小写
• 单元测试(如果使用)和模拟的指导原则
• 项的分组(例如,您有一个类的泛型和非泛型实现,它们是在同一个文件中,还是在命名约定后在单独的文件中?)
• 如何处理第三方依赖关系
• 促进诸如fxcop、stylecop和其他度量工具的使用

从我头顶上看几件事

源文件中有关最大方法长度、最大类大小和最大loc的指南将被使用。

此外,您还可以设置缩进、代码布局等方面的一些指导原则,但我发现在visual studio中使用设置并让开发人员为此导入相同的设置文件更容易做到这一点。这样人们就不必考虑这个问题,visual studio为他们做工作。

fxcop和类似的工具也可以自动检查最佳实践。因此,只需让fxcop文件检查您所关心的所有规则,就可以发布有关这方面的指导原则。不要在现有的代码库中引入大的fxcop检查,尽管尝试在一段时间内增加检查,这样人们就不会遇到1000个fxcop错误。

简而言之:

尽量缩短指导原则,只包括真正重要的东西。使它们易于阅读(您可以将命名约定作为示例类编写,例如,在其中用一些带有文本的额外框突出显示所有规则),并使用工具自动检查,这样开发人员就可以轻松地获得早期反馈。