代碼審查標準
代碼審查的主要目的是確保Google代碼庫的總體代碼運行狀況隨着時間的推移而不斷改善。爲此目的，設計了所有代碼審查工具和過程。
爲了實現這一點，必須權衡一系列折衷。
首先，開發人員必須能夠在他們的任務上取得進展。如果您從未向代碼庫提交過改進，那麼代碼庫將永遠不會得到改進。另外，如果審閱者很難進行任何更改，那麼開發人員就沒有動力在將來進行改進。
另一方面，審閱者有責任確保每個CL的質量都使得其代碼庫的整體代碼運行狀況不會隨着時間的流逝而減少。這可能很棘手，因爲隨着時間的推移，代碼庫通常會由於代碼運行狀況的小幅下降而退化，尤其是當團隊處於明顯的時間限制下並且他們認爲必須採取捷徑才能實現其目標時。
此外，審閱者對他們正在審閱的代碼擁有所有權和責任。他們希望確保代碼庫保持一致，可維護，以及“代碼審查中的查找內容”中提到的所有其他事項 。
因此，我們將以下規則作爲代碼審查中期望的標準：
通常，即使CL(Change List)並非完美，一旦處於肯定可以改善正在使用的系統的整體代碼運行狀況的狀態下，審閱者也應該批准它。
這是所有代碼審查指南中的高級原則。
當然，這是有侷限性的。例如，如果CL添加了審閱者不希望在其系統中使用的功能，則即使代碼設計得當，審閱者也可以肯定拒絕批准。
這裏的關鍵點是，沒有“完美”的代碼，只有更好的代碼。審稿人不應要求作者在批准前拋光CL的每一小塊。相反，與他們所建議的更改的重要性相比，審閱者應該平衡取得進步的需要。審稿人要追求的不是追求完美，而是 持續改進。總體而言，可以提高系統的可維護性，可讀性和可理解性的CL不應延遲幾天或幾周，因爲它不是“完美的”。
審閱者應該隨時發表評論，表示可能會更好，但是如果不是很重要，可以在其前面加上“ Nit：”之類的字樣，以使作者知道這只是他們可以選擇忽略的亮點。
注意：本文檔中沒有任何理由證明檢查CL肯定會 惡化系統的整體代碼運行狀況。您唯一要做的是在緊急情況下。
指導
代碼審查具有重要的功能，可以教給開發人員有關語言，框架或通用軟件設計原理的新知識。留下有助於開發人員學習新知識的評論總是很好的。共享知識是隨着時間的推移改善系統代碼運行狀況的一部分。請記住，如果您的評論純粹是教育性的，但對滿足本文檔中描述的標準不是至關重要的，請在其前綴前加上“ Nit：”，否則，表明並非強制要求作者在本CL中對其進行解決。
原則
技術事實和數據否決了意見和個人喜好。
在樣式方面，樣式指南 是絕對權威。不在樣式指南中的任何純樣式點（空格等）都是個人喜好問題。樣式應與那裏的樣式保持一致。如果沒有以前的樣式，請接受作者的樣式。
軟件設計的方面幾乎從來都不是純粹的樣式問題，也不是個人喜好。它們基於基本原則，應權衡這些原則，而不僅僅是個人意見。有時有一些有效的選擇。如果作者可以證明（通過數據或基於可靠的工程原理）幾種方法同樣有效，那麼審閱者應接受作者的偏愛。否則，選擇取決於軟件設計的標準原理。
如果沒有其他規則適用，則審閱者可以要求作者與當前代碼庫中的內容保持一致，只要這不會使系統的總體代碼運行狀況惡化。
解決衝突
在代碼審閱中發生任何衝突時，第一步應始終是使開發人員和審閱者根據本文檔以及《 CL作者指南》 和《審閱者指南》中其他文檔的內容達成共識。
當達成共識變得特別困難時，在審閱者和作者之間進行面對面的會議或視頻會議可能會有所幫助，而不僅僅是嘗試通過代碼審閱註釋來解決衝突。（但是，如果這樣做，請確保將討論結果記錄爲對CL的評論，以備將來閱讀。）
如果那不能解決問題，則最常見的解決方法是升級。升級的途徑通常是進行更廣泛的團隊討論，請一位技術負責人蔘加，要求代碼維護者做出決定，或者要求Eng經理提供幫助。不要讓CL坐下來，因爲作者和審稿人無法達成協議。
參考
https://google.github.io/eng-practices/review/reviewer/standard.html