Chen-hsiu Huang's Blog

其實想寫這個有點久了, 找點時間來談談為什麼我這麼討厭 compile warning

大約去年七月吧, 當時的 VC1 小組剛開工, 我們在確定使用哪個 source 為基準的時候, 第一件事就是把所有的 compile warning 解掉
解掉 warning 的原因有很多, 除了看起來乾淨清爽之外, 最重要的原因就是:

"不要讓真正會造成潛在錯誤的 warning 被埋沒在一堆無關緊要的垃圾中"

無視於 warning 的存在, 讓幾十頁數百個 warning 在編譯的時候捲過畫面
就好比放羊的孩子, "狼來了" 喊久了結果沒人相信, 總有一次遇上, 那結果就是蠻痛的

舉個簡單的例子: (真實發生在我們的 project 中)

int i, j;
for(i = 0; i < height; i++) {
  for(i = 0; j < width; j++) {
    // do something
  }
}

這裡很明顯有一個打錯的地方, compiler 會在這邊給出 warning, 跟你說 j 在第一次用到之前沒有被初始化
但如果 project 中老是擺著一堆 warning, 你就會去忽略他, 視而不見

"反正總是有一堆 warning, 沒有 error 就好"

這段 code 也許會 GP, 也許 run 出來的結果會錯, 也有可能運作起來也還算正常 (運氣好?)
但總有一天你會回來修這個 bug, 花你寶貴的時間一步步去 trace, 最後發現這個該死的 type error. 那麼,

"為什麼不在一開始的時候, 看到 warning, 就點兩下, 隨手把它解掉?"

除了礙眼之外, 這就是我這麼討厭 warning 的原因.

這樣的例子不多嗎? 其實陷阱很多, 例如:

int fun() 
{
  if(...) 
    return 1;
  else if(...)
    return 0;
  else if() {
    // no return in this block
  }
  // no return at the end
}

compile 會給個 warning, 跟你說不是所有的 program flow 都會 return 東西回去, 這就有潛在的危險
你當然可以說, 所有的流程我都設想好了, 那樣的情況不會發生

真的是這樣嗎?

半年後你回來要在這裡多加一個 if, 真的確定會好好的把整個流程想清楚而不會忽略一些東西?
有其他團隊成員 (這點很重要!) 來幫忙改這邊的 code, 你確定他會清楚這邊的所有運作細節?
三個月後你想起這段程式可以重複使用, 所以把其中幾個 if 搬到另個 project 的某個 function 使用
你真的確定不會產生預期之外的流程?
特別是在 COM 程式中, 幾乎 function 的傳回值都是 HRESULT, 你怎麼 copy-paste 都會對!

寫程式的時候, 最討厭, 最該死, 最容易產生的一種 bug, 我稱之為 "copy-paste bug"
發生在一堆, "看起來長的很像, 卻有一點不一樣" 的 code, 通常大家會把它 copy 過去, 再改一點點地方
可是往往我們容易忽略一些地方, 或是修了這個忘了那邊, 然後 bug 就被種下去了

防範的方法有兩種, 第一是盡量不要寫出那樣 "有點像, 又不太像" 的 code
第二就是, 注意 compiler 告訴你的每個 warning, 因為他可能真的在警告你!

我知道有的 programmer 是真的會下參數, 讓 compiler 列出所有 warning, 並把 warning 當成 error

有一個 warning 就不讓他 compile 過!

當然有些 warning 是真的很白痴, 所以有時候我也會下 #pragma 去關掉特定幾種 warning
但請確定: 必須要知道自己在做什麼. 而且像

int vec_cnt = (int) vec.size(); // size() 的 return 值是 unsigned int

這樣的寫法, 其實寫久習慣也就好了. 就像 Titan 說的: "養成習慣隨手做環保", "勿以惡小而為之"

我是這樣覺得啦, 除非你接手一個大 project, 而裡面有許多由來已久的 warning, 千頭萬緒, 不知該怎麼修起
不然自己寫的 code, 或是剛開始起步的 project, 實在沒有理由放著一堆 warning 假裝看不見