静态分析指在不执行代码的情况下审查代码。这样的代码审查可以是一个项目的一个阶段，或者当代码被转移给一个新的程序员（他也可能是6个月后的你自己）的时候自然发生。在两种情况下，目的都是通过阅读代码找到缺陷，理解它和找到不可能的情况。
不像测试，代码审计发生于当代码被写出来以后，因为，当然，在没写代码之前没有任何东西可以去审计。然而，被写出的代码拥有比仅仅肉眼能看到的更多的东西。在没有考虑两个不同方面的情况下，是不可能进行代码审计的；这两个方面是：它（代码）的架构和它的独特性。
代码架构
代码架构是一个组织代码的规则框架。比如，设计模式或 MVC 范式帮助分隔不同部分的代码，并且给事情的实践带来一些清晰（的概念）：控制器，模型和视图都拥有不同特定的任务。一般来说框架提供了很多这种架构。
代码架构在代码本身来说是很难阅读的。它需要（很多）前提知识：确实，在使用任何框架之前，一个人需要阅读它的文档，学习教程，然后开始写代码。范式的转换包括通过像从调用“echo”命令到写一个.phtml的文件。静态分析工具不可能通过代码学习知道一些类是不是控制器：这个必须事先就被知道。
项目的独特性
还有一些架构方面的规则只对应于一个项目。文件系统的结构通常在不同项目中有不同结构，Wordress 文件结构, Magento 文件结构, Code Igniter。还有用来存放缓存，临时文件，模块，第一版或第二版，测试等等的目录。这些必须学习了解而且不能在一个项目到另外一个项目之间重用（或者，基于经验，非常少）。
其他的项目的特性来源于业务逻辑，比如数据格式或算法。而且一些架构也从这些而来，比如帮助(helpers)或相关的REST服务。
通常的缺陷
最后，还有通常的缺陷。那些导致Bugs的代码问题，不和任何业务逻辑或项目的规则相关。这有可能是对一门(编程)语言的经典的误解, 或者一个快速黑客的情况。
之前的这些问题的主要不同是这些规则都关于PHP，对这些一个人可能找到各种不同的建议。学习这些应该已经做过，不应该属于和某个项目特例或架构选择问题。
作为一个总结，下面的表格显示了静态分析将会发现的各种代码和缺陷：
| 代码中可见 | 架构中可见 | |
|---|---|---|
| 通常缺陷 | 静态分析能够找到的问题：孤立指引错误(Dangling reference error) | 静态分析找到踪迹（traces），但是不能下结论:只有模型对数据库做查询；只有模板文件含有HTML(如果适用） |
| 项目特性 | 当特别的规则定义好后，它有可能被静态分析找到：一个电话号码的格式必须是(\d\d)-(\d\d)-(\d\d)-(\d\d)-(\d\d) | 需要特别的规则和对架构了解：电话号码存于CHAR(10)字段，没有分隔符(i18n在模板文件里做) |
可行的静态分析
静态分析的一个主要的限制是列出可以强制执行的规则。对PHP有一组规则，比如PSR, ClearPHP或者 object Calisthenics提供了一个很好的通用的参考。
下一步是对一个项目提供一组独特的规则。这个包括：
- 从其他各种参考中选择一些规则
- 帮助Helpers方法
- 数据格式（日期，电话号码，ISBN的解析，验证，显示和操作）
- 配置（变量名字，定义，访问）
- 存储结构（类和存储直接的连接，必须被存储的对象）
- 算法（CC信用卡验证，VAT数字的验证）
- 业务逻辑
- 对象代理（永远不调用数据API，永远使用这个对象…)
- 项目的可做和可不做的东东（添加一些人性的味道）
很常见的情况是，这些规则都是一步一步在进行中完善的。尽快地收集它们使得每个人可以撰写合法的代码。它也允许加入一个静态分析的工具，那样可以监控应用程序的代码并基于规则提供系统的反馈。只要是代码标准(conding standards)不可知，它们是不可能查询和应用上。
面向对象实践Object Calisthenics( Cal • is • then • ics – /ˌkaləsˈTHeniks/)
作为一个例子，这个是 面向对象实践(Object Calisthenics) 编程练习在上面的表里几个规则。由于这是不仅仅局限于PHP的哲学(规范)，这里没有“通常缺陷”。在你的自己的项目中适用它们。
| 代码中可 | 架构中可见 | |
| 通常缺陷 |
|
|
| 项目特性 |
|
|
Don’t Abbreviate：属于代码约定，不在这里讨论。
English: http://178.62.231.40/applicable-static-analysis/