使用编码标准可以避免的错误

我正在寻找统计数据（或估计值）来支持编码标准有助于减少错误的说法。硬数字会很好，尽管我没有发现太多东西。我什至研究过各种开源项目的错误跟踪，但是并不是很成功地找到了我需要的东西。外面有人知道我可以找到这个地方吗？还是你们中的任何人对任何存在漏洞的开源项目做出了贡献，而这些漏洞可以通过更好的编码标准来避免？

单独使用编码标准不会减少错误。编码标准是完善的软件开发过程的一部分，可减少错误。

以下两篇文章研究了声音软件工程过程对减少缺陷的统计影响，您可以以此为起点：

• 减少软件缺陷的十大清单，该调查调查了自1987年以来基于经验的软件工程的改进情况
• PSP数据过程的批判性分析，研究从个人软件过程收集的统计数据，以及PSP对软件错误常见原因的影响

编码“标准” ...有很多可以标准化的开发领域。我们在谈论编码约定，例如命名标准等吗？还是我们在谈论更深层次的内容，例如TDD / BDD，CI等？

我可以告诉您，通过CI强制通过测试并具有良好的代码覆盖率，坚持“测试优先”的方法确实可以减少客户端发现的错误的数量。开发人员和质量检查人员进行的自动测试也是发现错误的相对“便宜”的方法，因为它们通常具有非常短的反馈时间。您可以知道，通过运行约45秒的单元测试，您没有写出您认为的内容。几个小时的集成测试将发现无法按计划将所有内容整合在一起的地方，并且端到端和自动UI测试可以在非常高的级别上快速发现软件中的功能故障。

它们还可以防止回归。您发现了一个错误。您编写了一个将证明不再发生行为的测试，对代码进行编码，直到测试通过为止，现在您将拥有一个测试，可以确保从现在开始，该错误不再是问题。根据我的经验，这是新错误的主要来源；修复一件事破坏了其他东西，而您的开发人员对该修复程序的测试可能无法涵盖现在已经破坏的其他情况。破坏曾经有用的东西对您的客户来说是一个巨大的危险信号。

最后，您作为此方法学的一部分构建的这种自动测试结构将很容易为您提供一个环境，您可以在此环境中立即发布新版本的软件。“嘿，您刚刚修复的错误已经引起了一些真正的头痛；何时可以在新版本中准备好该错误？” 单击 “哦，构建服务器完成将其发布到下载页面后，大约需要5分钟”。

至于基本的编码约定，例如标准化变量名等，我发现其中大多数都不太有用，而且更令人讨厌。这些是“很棒的标准，因为有很多可供选择”。您认为PascalCased和camelCased标识符之间的区别可能不是别人的想法。前导下划线，名称长度限制（或方法/字段名称讲述故事的要求）；除了由编译器强制执行的约定或特定于语言的库代码中常见的约定外，现代IDE可以告诉您需要了解的有关变量或函数的所有信息，包括您是否应该在特定的变量中使用它。环境。另外，运行代码约定检查通常会返回您无法或不可以的代码问题 不想更改，例如使用不同标准集的第三方库，或可能符合Win API命名标准而非您本国语言标准的互操作代码。最后，您在代码中添加了残篇，以使您的工具忽略代码中的残篇。

每个SQL注入漏洞都是可以通过编码标准避免的缺陷。SQL注入漏洞的统计信息可以通过AFAIK获得。

使用编码标准可以避免每个缓冲区溢出漏洞。有关这些的统计信息也可能可用。