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

公司以往的作法是這樣，你先 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++ 而言，我剛剛稍微玩了一下 RATS 和 flawfinder，他們的確能夠提供一些有用的資訊，像是不該使用 gets，或是使用 strcpy 會造成的危險他都能一一列出。

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