【发布时间】：2008-11-18 15:41:46
【问题描述】：
我目前正在处理一个大型项目，其中许多开发人员随着时间的推移工作并且代码很糟糕。经过多次重构，我们现在到达了一个点，代码没问题。现在我在想“ok”是什么意思——可能对每个人来说都是不同的。
您认为可以指定“ok”吗？什么是重要的？ NDepend 指标？测试覆盖率？注释？编码风格？文档？
我知道已经有很多关于编码风格或评论的话题（例如here）。这个问题只是关于哪些事实是重要的。
【问题讨论】：
【发布时间】：2008-11-18 15:41:46
【问题描述】：
我认为，对于任何重要的项目，您都应该有适当的编码指南（样式、cmets 等）和指标，以了解它们是否被遵循。您列出的清单是一个很好的开始。
【讨论】：
-
我同意，只要指导方针意味着如果你能提出一个很好的理由，你就可以做一些不同的事情。如果这是一个很好的理由，应该调整指南以采用它。
你混淆了两种不同的东西。
您谈论编码风格，但随后您提到测试覆盖率、指标等。
当然可以指定编码风格——所有需求文档必须声明“为了代码维护和一致性，本项目将遵循这些编码风格和标准。”
然而，一般来说，大多数项目只需要“良好的行业实践”和“整个项目的一致编码风格”，并将其实际定义和实施留给开发人员。
但是，您正在讨论的其他问题，需要重构、测试、覆盖等的不良代码（我也会抛出 LINT 和静态分析），这些都应该明确指定和要求。没有理由将它们排除在规范之外 - 它们是显示哪种类型的编码错误（或者，在风格和错误代码之间的模糊线上，哪种类型的编码模式可能产生错误代码）的硬指标在任何给定的代码中，它的性能如何，以及测试显示正确操作的程度。
在大型项目中，客户将与主要开发人员坐下来检查 LINT 配置，例如，以确保它满足他们的需求，并且没有任何琐碎的错误会减慢开发速度。
所以，简而言之，是的，所有这些都可以（并且应该，恕我直言）为任何重要的项目指定。
-亚当
【讨论】：
你说得对，每个人的情况都不一样。也就是说，一旦您定义了期望，保持它向前发展的最佳方式就是通过频繁的代码审查。
人们，尤其是项目中的新人，总是带着自己的风格。代码审查有助于使代码雌雄同体。
【讨论】：
有很多东西可以说是ok/good code的属性。
- 编译时没有错误或警告
还有一些关于这个主题的其他主题...
【讨论】：
有许多事情可以提高项目的质量，而这些事情与代码和工具无关。
需求管理。 有一些流程来对您的要求进行质量控制。它们有意义吗？谁要求的？他们是提出这些要求的合适人选吗？
测试设计。 根据要求而不是实现来构建测试。 不要让您的编码人员进行测试！
测试一切——每次。 完成每个版本的完整测试周期，没有次要版本。
根据我的经验，诸如代码度量和代码标准之类的东西从来没有真正起作用。你会知道谁是无赖编码员；您不需要正式的流程来识别它们。
真正能提高质量和输出的一种技术是代码审查。您需要一些纪律和骨干才能让您的三个资源花一天时间审查 5 天的工作。但是没有什么能如此彻底地揭示潜在的问题，而且，该死的，如果人们知道下周有人会批评它，他们只会写出更好的代码。
【讨论】：
StyleCop ... 还有，FxCop ...
团队绝对应该标准化他们的风格。一些个人选择的空间，但一个团队绝对应该标准化他们的风格。代码更易读、更易维护、更容易审查等等等等。
【讨论】：
某种准则（样式不如内容 IMO 重要），例如最佳模式/实践，但更重要的是代码审查。
【讨论】：