軟件開發活動應包括源代碼審查，以提高軟件質量并防止或消除軟件缺陷，靜態分析工具可以自動化該活動的重要部分，同時降低其成本。代碼審查通常基于定義應識別和糾正哪些違規或缺陷的編碼標準和/或檢查表進行。

尤其是 C 語言，編碼標準的流行示例是 MISRA C 和 CERT C，它們分別提供了增強安全性和安全性的指南（盡管這兩個范圍之間存在一些重疊）。MISRA C 指南的制定特別關注其靜態分析的可執行性，這反映在可以自動實現的大量執行中。

但是，有兩個不可避免的限制阻礙了全自動執行：

1. 在某些情況下，將靜態分析器完全執行準則所需的所有信息形式化是不切實際的或不可能的。

2. 對于某些準則，即使所有信息都可用于算法，即使算法可以擴展以清除任何特定的假陽性或假陰性。

在最新版本的 MISRA C （2012） 中，這些限制反映在指南的分類中。當可以提供足夠的信息時，將指南歸類為規則；否則，它被歸類為指令。當可以構造通用算法時，將規則分類為可判定的；否則，它被歸類為不可判定。

指南有不同的優先級和不同的范圍，但為了初步了解自動執行的潛在程度，159 條指南分為 16 條指令、27 條不可判定規則和 116 條可判定規則。

指令的一個示例是所有代碼都應可追溯至文件化要求。在這種情況下，僅向靜態分析器提供整個源代碼和用于構建應用程序的編譯器配置是不夠的。首先，將任何重要的要求形式化是不切實際的或不可能的。

可判定規則的一個示例是不應使用#undef。在這種情況下，可以構造一個算法來掃描任何源代碼并報告所有出現和僅出現#undef 預處理指令的情況。

不可判定規則的一個例子是項目不應包含無法訪問的代碼。你能想象一個算法可以精確識別任何項目中所有無法訪問的代碼實例嗎？

不可判定性可能是一個相當不直觀的概念。軟件開發人員通常會面臨一系列需要解決的問題，從微不足道到不可能，其中可以實現的限制通常由熟悉的因素決定，例如缺乏信息、問題過于復雜、資源消耗急劇增加域范圍等

除了所有這些因素之外，編碼標準的自動執行（或任何其他自動檢測軟件缺陷的非正式方式）涉及構建原則上可以自我分析的算法，這會引入一個循環性，如果一個額外的基本限制會導致一個悖論 - undecidability - 不妨礙構建一個健全和完整的分析儀。

審核編輯：郭婷