軟件開發(fā)活動應包括源代碼審查，以提高軟件質量并防止或消除軟件缺陷，靜態(tài)分析工具可以自動化該活動的重要部分，同時降低其成本。代碼審查通?；诙x應識別和糾正哪些違規(guī)或缺陷的編碼標準和/或檢查表進行。

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

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

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

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

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

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

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

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

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

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

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

審核編輯：郭婷