我们应该使用什么标准来判断代码质量?

我认为对于任何非trival项目,您都应该有适当的编码准则(样式、注释等)和度量标准,以知道它们是否被遵循。你列出的清单是一个很好的开始。

你把两件事搞混了。

您讨论的是编码风格,但随后提到测试覆盖率、度量等。

当然可以指定编码样式-所有需求文档必须声明的是“为了代码维护和一致性,此项目将遵循这些编码样式和标准。”

然而,一般来说,大多数项目只需要“良好的行业实践”和“整个项目的一致的编码风格”,并将其实际定义和实现留给开发人员。

但是,您正在讨论的其他问题,需要重构的错误代码,测试,覆盖率等等(我也会抛出lint和静态分析),这些都应该显式地指定和要求。没有理由将它们排除在规范之外——它们是一种硬指标,可以显示在任何给定代码中可能出现哪种类型的编码错误(或者,在样式和错误代码之间出现模糊线,哪种类型的编码模式可能产生错误代码),它的性能如何,以及如何测试表明操作正确。

例如,在大型项目中,客户将与领先的开发人员坐下来讨论lint配置,以确保它满足他们的需求,并且没有轻率的错误减慢开发速度。

所以,简而言之,是的,所有这些都可以(而且应该,imho)为任何有意义的项目指定。

-亚当

你说得对,每个人都不一样。也就是说,一旦定义了期望值,保持它向前发展的最佳方法是通过频繁的代码检查。

人们,特别是项目中的新人,总是带着自己的风格。代码审查有助于使代码中性化。

有很多东西可以说是ok/good代码的属性。

• 编译时没有错误或警告

还有一些关于这个话题的其他话题…

有很多事情可以提高项目的质量,而这些事情与代码和工具无关。

1. 需求管理。 有一些过程来应用质量控制到你的要求。它们有意义吗?谁要的?他们是提出这些要求的合适人选吗?

2. 测试设计。 根据需求而不是实现来构建测试。 不要让你的程序员做测试!

3. 每次都要测试。 对每个版本进行完整的测试周期,不存在次要版本。

以我的经验,像代码度量和代码标准这样的东西从来没有真正起作用。你将知道谁是无差拍编码;你不需要一个正式的过程来识别他们。

真正能提高质量和输出的技术是代码评审。你需要一些纪律和骨干力量,让你的三个资源花一天五天的工作。但没有什么能如此深思熟虑地揭示出潜在的问题,而且,该死的是,如果人们知道下周有人会对其进行批评,他们只会写出更好的代码。

时尚警察…还有,fxcop…

一个团队绝对应该使他们的风格标准化。一些个人选择的空间,但一个团队绝对应该标准化他们的风格。代码更具可读性、可维护性、更易于审查等。

一些准则(样式比内容imo不重要),例如最佳模式/实践,但更重要的是代码审查。