許多人認為，如果源代碼編譯干凈，激活所有警告，那么它就可以進入驗證階段，例如測試或代碼審查。但是，假設如果代碼已干凈地編譯，那么存在的任何錯誤一定是由對需求的解釋而不是它們的實現(xiàn)引起的，這是危險的。Wojciech對這一假設進行了實證評估，并證明與專用靜態(tài)分析和編碼標準執(zhí)行（CSE）工具生成的警告范圍相比，任何編譯器提供的警告范圍都非常有限。

一種普遍的觀點是，如果源代碼編譯干凈，所有警告都打開，那么它就可以進行驗證，例如測試或代碼審查。這種假設的危險在于，如果代碼已經(jīng)編譯干凈，那么存在的任何錯誤都必須在需求的解釋中，而不是在它們的實現(xiàn)中。然而，對這一假設的實證評估最終表明，與專用靜態(tài)分析和編碼標準執(zhí)行（CSE）工具生成的警告范圍相比，任何編譯器提供的警告范圍都受到嚴重限制。

本文的比較使用了GNU Common C++“2”版本1.6.3，這是一個大約42，000行代碼的真實代碼庫。由于這是一個跨平臺庫，因此它不支持任何特定的編譯器，并且可以用作任何編譯器可能期望處理的代表性示例。其適中的大小允許手動檢查所有編譯器警告的準確性，同時確保其多樣性和數(shù)量不平凡。

檢查的四個編譯器是GCC，Visual C++，C++Builder和Intel C++ Compiler，以及靜態(tài)分析和CSE工具，表明如果開發(fā)人員過于依賴編譯器來識別編碼缺陷，他們可能會發(fā)現(xiàn)他們的代碼不可維護，可重用或可移植。此外，Visual C++“團隊版”使用“代碼分析”功能補充其標準編譯器警告，其輸出包含在這些結(jié)果中。

生成警告輸出

在實踐中，這四個編譯器中有一個遺漏的每一個缺陷都會對代碼庫的質(zhì)量產(chǎn)生影響，無論是可維護性、可移植性還是可重用性。這在部署代碼時是一個重大威脅，盡管大多數(shù)示例源代碼都通過了編譯器的架構(gòu)檢查參數(shù)。

由于這些編譯器基于不同的前端，因此每個編譯器可能會發(fā)出不同的警告。表 1 并排比較了每個編譯器和靜態(tài)分析工具生成的不同警告，用于我們比較中使用的代碼庫：GNU Common C++ “2”。使用編譯結(jié)果時可用的每個編譯器的最新版本，并啟用最大警告級別。（表 1 的標題行指示使用的確切編譯器版本和選項。不是相對于這些編譯器進行基準測試，而是將它們的警告輸出與靜態(tài)分析器進行比較以進行C++。

表 1：默認檢測比較 – 比較的基礎和每個百分比數(shù)字是編譯器和給定類別中的靜態(tài)分析工具報告的不同警告之間的比率。標題行詳細說明了用于啟用最大警告級別的確切編譯器版本和選項。

如表中最后一行所示，CSE 工具生成了超過 400 個警告，而測試的編譯器甚至沒有一個設法返回 20 個警告。事實上，根據(jù)經(jīng)驗，靜態(tài)分析識別的警告是所有四個編譯器中最好的 25 倍 - 啟用了代碼分析的可視化C++（/analyze 選項）。值得注意的是，如果未啟用此功能，Visual C++ 在所有測試的編譯器中生成的警告最少。

表 1 中的第一列數(shù)據(jù)顯示了靜態(tài)分析工具也檢測到的每個編譯器生成的警告的百分比。請注意，重疊程度很高，平均 84% 的編譯器警告由 CSE 工具復制。比較的這一面只是為了完整性，因為無論是否執(zhí)行靜態(tài)分析，開發(fā)人員都需要啟用編譯器警告。

表 1 的其余行顯示了比較的另一面：編譯器標記了多少靜態(tài)可檢測的內(nèi)容？很明顯，編譯器警告避開了“C++的效率和使用”類別。這是意料之中的，因為編譯器優(yōu)化是在后端執(zhí)行的，通常是靜默的。但是，值得注意的是，專用的 CSE 工具在此類別中有一系列檢查，專注于低效設計，與低級編譯器優(yōu)化不同，這些檢查無法自動糾正。

錯過的常見警告

可移植性是編譯器庫中缺少的常見警告類別。只有 C++Builder 生成了一個可歸類為可移植性問題的警告，而靜態(tài)分析工具標記了 17 個警告。這些表示符合 ISO C++ 語言定義的構(gòu)造，但可能會導致不同的編譯器實現(xiàn)出現(xiàn)問題。編譯器供應商通過提供 ISO C++ 的擴展來鎖定開發(fā)人員的情況并不少見，可移植性在他們的議程上并不重要也就不足為奇了。這代表了可移植性問題的另一個方面，即符合 ISO C++，這可以通過靜態(tài)分析工具中的單獨警告類別來解決。

對于大多數(shù)編譯器供應商來說，ISO C++合規(guī)性歸結(jié)為接受盡可能多的有效C++代碼，同時回避檢測不一致代碼的問題 - 通常是他們自己的語言擴展。檢測 ISO C++不合格是 CSE 工具的優(yōu)勢之一，這在表 1 中很明顯。很明顯，大多數(shù)編譯器警告可以歸類為（代碼）“設計問題”和“可維護性”，其中一些警告非常小，值得將它們降級為樣式問題。然而，即使對于這些重點領域，與靜態(tài)分析工具相比，其覆蓋率也遠非全面，對于最佳競爭者 - 具有代碼分析功能的可視化C++，覆蓋率為7%。

編譯器傳統(tǒng)上避免的其他警告類別包括：命名約定、代碼布局、復雜性指標閾值以及禁止某些關(guān)鍵字（例如 throw）和函數(shù)（例如 malloc），但 Visual C++ 代碼分析功能有一個明顯的例外，該功能具有硬連線警告，用于使用 _alloca、_snprintf 和 TerminateThread 函數(shù)。由于這不如靜態(tài)分析工具的可配置檢查（允許指定任何函數(shù)）全面，因此獲得了半分，使該編譯器在本地（公司特定）標準執(zhí)行方面得分為 10%。實施上述區(qū)域的主要好處是增強了代碼的可重用性，從表 1 中可以明顯看出，編譯器實際上尚未利用這一點。

在比較每個工具生成的實際警告實例時，將原始警告計數(shù)制成表格并不是特別有啟發(fā)性，因此常見的C++編碼標準將作為比較的客觀基礎。從表 2 可以看出，與 CSE 工具記錄的違規(guī)行為相比，沒有一個編譯器提供任何明顯的高完整性C++、JSF++ 或 MISRA C++ 強制實施。

表 2：編碼標準執(zhí)行 （CSE） 比較

全面性教育工具：最全面/可轉(zhuǎn)移的路線

一個常見的誤解是，編譯器警告是靜態(tài)分析源代碼的充分方法。與專用的靜態(tài)分析和 CSE 工具（如 PRQA 的 QA?C++）相比，市場領先的編譯器提供的警告范圍有限。此外，可用的少數(shù)檢查往往集中在代碼錯誤行為和可維護性問題上，而可重用性和可移植性問題完全被忽視。專用的 CSE 工具提供了所有這些領域的全面實施，同時保持編譯器不可知性，因此代碼庫和開發(fā)環(huán)境不必局限于特定的編譯器和平臺。

審核編輯：郭婷