静态代码分析的真正好处是什么？

诸如pc-lint或QAC之类的工具可用于在代码库上执行静态代码分析。

以我的经验，静态分析通常会产生大量的噪音，例如，警告不是真正的错误，但却以某种方式违反给定规则集中的规则之一。关闭某些规则（无论是完善规则集还是通过代码中的特殊注释）可能都是一个麻烦的过程。

静态代码分析的真正好处是什么？

我在一个使用名为Coverity Prevent的商业静态代码分析系统的地方工作，真是太神奇了！它确实非常复杂和智能。

我们向它扔了大约18 GB的开放源代码和专有C和C ++代码，它会通过代码路径进行跟踪，并迅速发现细微的bug，这将使人类永远追根溯源。查明通常是Heisenbug的东西也很棒。

它每隔几天就会在我们的代码库中运行，并且一个不错的功能是我们可以告诉它“这不是一个真正的错误”，并且它会在将来记住这一点。

陷阱是，Coverity确实很昂贵。他们没有公布成本，但我觉得对于商业项目，每年的起价为数十万美元。但这可能使我们不必雇用一大堆开发人员和质量检查人员，因此总的来说，我们的管理层似乎认为这是一个不错的选择。

有了这些经验，我对静态代码分析非常满意。

开始使用新语言时，很高兴有一位教练。这就是我对静态分析工具的看法。我写了很多JavaScript，一开始我就养成了一些坏习惯，主要是因为我从早期的语言中转移了一些东西。Javascript非常灵活，因此您几乎可以避免任何事情，但是如果我让jslint警告我某些模式，那么我将从一开始就选择更好的编码模式，而不必稍后再学习。

静态分析器基本上是机器辅助的代码审查。他们会指出在常规测试中可能遗漏的可疑区域。

例如，作者真的是想在这种条件下进行作业吗？

if (x = 1) {
    ...
}

或者，一个菜鸟混淆了词法转换：

char* number = "123";
int converted = number;

当然，静态分析仪需要进行调整。同样，修订控制，Wiki，错误跟踪器，漂亮的打印机和其他工具也需要进行一些设置。项目越大，初期劳动的报酬就越好。

从顾问的角度来看，每个静态分析工具都会产生一些噪音，但并非所有静态分析器都是一样的。诸如Coverity，Klocwork，Grammatech之类的静态分析工具都具有良好的分析技术，这些技术应该可以产生更准确的结果。如果您进行更多的调整和调整，通常可以获得更好的结果（毕竟，静态分析器必须能够在从小型医疗设备到网络操作系统的所有不同类型的代码上运行）。定义“噪声”还取决于您构成可修复报告的标准。一方面，一些开发人员将所有未修正的报告都标记为“假”（即使编写得很差的代码，他们也没有时间修正），另一方面，

这些工具中的一些更着重于集中分析，而其他一些更着重于台式机，尽管这三个工具均具有支持这两个工具的功能。正如@Bob所说，它们要花钱。

在我以前的公司中，我们使用了Parasoft的静态分析仪。在团队内部，据信至少有60％的运行时错误在编译之前被捕获。

通过对软件代码进行手动检查，也可以在不使用工具的情况下执行静态分析。这通常是提高代码质量的最经济有效的方法。

第二个最佳选择是投资一个或多个高端静态分析工具（例如前面提到的Coverity或KLOCwork）。例如，由于这些工具执行的分析比棉绒要深得多，因此信噪比要好得多。

由于噪声水平高，我考虑将皮棉用作第三个选项。将棉绒应用于现有项目可能是一项艰巨的任务。

总体而言，近年来静态程序分析取得了很大进展。当前的静态分析工具能够执行深入的过程间分析，并且可以自动识别例如过程的前置条件和后置条件。这也可以为以后的代码审查提供很大的帮助。

由于误报率很高，因此您不应为每个编译使用静态分析工具（如lint或FindBugs）。

相反，这是一个不错的检查，一旦发现错误并无法解决，就可以进行咨询。在这种情况下，您可以接受误报，并且您可能已经缩小了错误的可能来源。例如，如果您甚至不执行某些模块就重现了错误，则可以忽略FindBugs为他们所说的话。当您查看一段代码并认为它说了一件事，而编译器按字面意义读取时（例如，在Java中，您使用的equals方法采用类的类型而不是Object）时，这特别有用。

您还可以将静态分析工具作为开发过程的一部分：当开发人员进行代码审查时，他们还应在其上运行FindBugs。简而言之，它很有用，但是您不会像编译器或文本编辑器那样经常使用它。