我的習慣是如果函式回傳值為 true 或 false 的話，便不會在條件判斷式中寫出來。你寫的這種 coding style 也同樣可行，我想只要維持一致的寫作風格就行囉。

for (int i = 0; i < 10; ++i)
{
if (true == ThisIsTrue)
{
Myfn1();
}
}

我也同意你的看法，覺得 Exception 不應該完全禁用。但是以文件中的說明來看，Google 由於 Legacy Code 整合不易的因素，而決定不採用 Exception 機制，我覺得也算是一項合理的考量。另外一點，或許是因為應用於開源專案之故，為了避免經常發生的 Exception 濫用與誤用情形，所以才採取比較保守的錯誤回報機制。

我認為，這份文件的價值在於 Pros、Cons 與 Decision 的理由都寫得非常清楚明瞭，提供給程式設計者一個不錯的思考方向。至於是否完全同意其中所有的 Coding Decision？我想還是需要 Case-by-Case 攤開來檢視才行。畢竟，現實狀況總非如此理想可期，不是嗎？ ：P

謝謝您的回應。

這是許多 Google Open Source 專案所遵循的 Coding Style 文件。內容除了一般的程式碼撰寫風格規範之外，還有對於一些 C++ 特有的 Feature 做出使用與否的決定，例如 Default Arguments、Exceptions、RTTI 與 Casting 等等特徵，每一個項目都有寫出 Pros、Cons 意見，以及最終的 Decision。

我覺得這份文件很有參考價值，可以按照自己的需求修改後，做為遊戲專案的 Coding Style 準則。

在一個小組裡，常常有一兩個很喜歡自我程式風格的人，而他們的風格總是離不開上面說到的那種、又密又小又不加註解，用了一堆define和printf來debug最後卻沒有移除的…真的會造成其他組員的很多不便。因此可以理解，面試之前為什麼主考人都會請你寄一些舊程式碼了。

半路：
實際情況的確是如此。
所以 Code Review 的程序就很重要，不只能夠找出潛在的錯誤與臭蟲，更能夠讓所有人的版面配置與寫作風格逐漸趨於一致化。風格不一致的程式碼，真的會對整個團隊造成不少隱性但是要命的影響。

要寄程式碼去面試工作的人，別忘了先整理一下自己程式碼的服裝儀容嘿～ XD