靜態代碼分析工具可簡化編碼過程，檢測出錯誤并幫助修復。PVS-Studio 是一個用于 C/C++ 的靜態代碼分析工具。該團隊檢測了 200 多個 C/C++ 開源項目，包括了 Unreal Engine、Php、Haiku、Qt 和 Linux 內核等知名項目。

下面這個 Bug 是在 Source SDK 的源代碼中發現的。

錯誤代碼：

這種錯誤的例子代碼量都非常大，我盡可能地選取其中最小的一部分，但是很抱歉，代碼看起來依舊很冗長。

enum PhysGunPickup_t{ PICKED_UP_BY_CANNON, PUNTED_BY_CANNON, PICKED_UP_BY_PLAYER,};enum PhysGunDrop_t{ DROPPED_BY_PLAYER, THROWN_BY_PLAYER, DROPPED_BY_CANNON, LAUNCHED_BY_CANNON,};void CBreakableProp::OnPhysGunDrop(...., PhysGunDrop_t Reason){ .... if( Reason == PUNTED_BY_CANNON ) {  PlayPuntSound(); } ....}

解釋：

Reason 變量是屬于枚舉類型 PhysGunDrop_t，卻用它和屬于另一個枚舉類型的常量作比較，這種比較顯然是個邏輯錯誤。

但是這種 bug 模式很普遍，我甚至在像 Clang、TortoiseGit 和 Linux Kernel 這種項目中都有碰到過。

為什么會如此頻繁？因為在標準C++中，枚舉類型本來就不是類型安全的。到底什么該跟什么做比較，很容易讓人混淆。

正確代碼：

我不太確定這段代碼的正確版本應該是什么樣的，我猜想 PUNTED_BY_CANNON 應該用 DROPPED_BY_CANNON 或者 LAUNCHED_BY_CANNON 來替代。此處就用 LAUNCHED_BY_CANNON 來代替了。

if( Reason == LAUNCHED_BY_CANNON ){ PlayPuntSound();}

建議：

如果你是用C++寫代碼，還沒碰到過這種bug，算你幸運；我強烈建議你從現在開始在代碼中使用“枚舉類”。

對于C++11中的一些新特性，我沒有太多信心。就拿auto關鍵字來說吧，我相信如果頻繁使用的話，會有很多壞處的。 我是這么看的：比起寫代碼，程序員會花更多的時間閱讀代碼，所以我們必須確保程序的可讀性很強。 C語言中， 所有變量都必須在函數的一開始就聲明，那么在函數的中間或者末尾編輯代碼時，沒那么容易推測出某個Alice變量到底是什么意思。這也是為什么變量的命名規范會這么多樣化？ 例如，前綴命名法PfAlice就代表指向浮點數的指針。

C++中你可以隨時隨地聲明變量，這是一種很好的編碼風格。因而使用前后綴命名也不再那么受歡迎了。接著auto關鍵字出現了，直接導致程序員又開始使用各種各樣很難理解的構造形式， 諸如auto Alice= FOO(); 之類的。 Alice？誰是TM的Alice？（為保留原文本意，此處翻譯稍有不文明）

很抱歉，又偏離我們的主題了。 我想告訴大家的是一些新的特性都有它的好壞兩面性。 但是對于“枚舉類”， 我堅信使用它有百利而無一害。

在使用枚舉類的時候，必須明確指出指定的常量屬于哪個枚舉類型，以免在代碼中出現錯誤。使用枚舉類更新后的代碼如下：

enum class PhysGunDrop_t{ DROPPED_BY_PLAYER, THROWN_BY_PLAYER, DROPPED_BY_CANNON, LAUNCHED_BY_CANNON,};void CBreakableProp::OnPhysGunDrop(...., PhysGunDrop_t Reason){ .... if( Reason == PhysGunDrop_t::LAUNCHED_BY_CANNON ) {  PlayPuntSound(); } ....}

說真的，修復舊代碼的確會有一定困難，但我強烈推薦你們在代碼中使用枚舉類，你的項目定會從中受益。

我覺得在這兒詳細介紹枚舉類沒有多大意義，有興趣的可以自己去了解一下的。

這個錯誤是用靜態代碼分析工具 PVS-Studio 檢測到的，錯誤信息為：V556 對不同枚舉類型的值進行比較：Reason == PUNTED_BY_CANNON。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對武林網的支持。如果你想了解更多相關內容請查看下面相關鏈接