靜態(tài)代碼分析工具可簡化編碼過程，檢測出錯(cuò)誤并幫助修復(fù)。PVS-Studio 是一個(gè)用于 C/C++ 的靜態(tài)代碼分析工具。該團(tuán)隊(duì)檢測了 200 多個(gè) C/C++ 開源項(xiàng)目，包括了 Unreal Engine、Php、Haiku、Qt 和 Linux 內(nèi)核等知名項(xiàng)目。

下面這個(gè) Bug 是在 Source SDK 的源代碼中發(fā)現(xiàn)的。

錯(cuò)誤代碼：

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

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，卻用它和屬于另一個(gè)枚舉類型的常量作比較，這種比較顯然是個(gè)邏輯錯(cuò)誤。

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

為什么會(huì)如此頻繁？因?yàn)樵跇?biāo)準(zhǔn)C++中，枚舉類型本來就不是類型安全的。到底什么該跟什么做比較，很容易讓人混淆。

正確代碼：

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

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

建議：

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

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

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

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

在使用枚舉類的時(shí)候，必須明確指出指定的常量屬于哪個(gè)枚舉類型，以免在代碼中出現(xiàn)錯(cuò)誤。使用枚舉類更新后的代碼如下：

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();
 }
 ....
}

說真的，修復(fù)舊代碼的確會(huì)有一定困難，但我強(qiáng)烈推薦你們?cè)诖a中使用枚舉類，你的項(xiàng)目定會(huì)從中受益。

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

這個(gè)錯(cuò)誤是用靜態(tài)代碼分析工具 PVS-Studio 檢測到的，錯(cuò)誤信息為：V556 對(duì)不同枚舉類型的值進(jìn)行比較：Reason == PUNTED_BY_CANNON。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)我們的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接