你今天 static code analysis 了嗎?

最近才稍微看了一下手邊專案的程式碼,不能說有什麼太多的問題,只是就制度面而言,其實還有更多可以改善的地方。

公司以往的作法是這樣,你先 check-in code,然後等到一個禮拜的 static code analysis 再進行全面性的更正。但我想 check-in 之後的 static code analysis 只能說是最後一道防線,在這之前,就只能端看開發者的自由心證。

所以,如果要等公司的工具告訴你問題之前,為什麼不先想辦法先作一次呢?自己先作一次有幾點好處。

  • 確保 check-in 的 code 跑出來的 unit test 結果正確,降低事後修正造成的副作用
  • 減少 submit log 上太多與 feature 無關的 log(例如 strcpy fixing)

而現有的 static code analysis 的工具你可以參考 List of tools for static code analysis 然後選擇用的順手的一個,以 C/C++ 而言,我剛剛稍微玩了一下 RATSflawfinder,他們的確能夠提供一些有用的資訊,像是不該使用 gets,或是使用 strcpy 會造成的危險他都能一一列出。

然而 static code analysis 就真的足夠了嗎?我想答案勢必是否定的。