總結
- 保持友善。
- 解釋你的推理。
- 在給出明確的指示與只指出問題並讓開發人員自己決定間做好平衡。
- 鼓勵開發人員簡化代碼或添加代碼註釋，而不僅僅是向你解釋複雜性。
禮貌
一般而言，對於那些正在被您審查代碼的人，除了保持有禮貌且尊重以外，重要的是還要確保您（的評論）是非常清楚且有幫助的。你並不總是必須遵循這種做法，但在說出可能令人不安或有爭議的事情時你絕對應該使用它。 例如：
糟糕的示例：“爲什麼這裏你使用了線程，顯然併發並沒有帶來什麼好處？”
好的示例：“這裏的併發模型增加了系統的複雜性，但沒有任何實際的性能優勢，因爲沒有性能優勢，最好是將這些代碼作爲單線程處理而不是使用多線程。”
解釋爲什麼
關於上面的“好”示例，您會注意到的一件事是，它可以幫助開發人員理解您發表評論的原因。 並不總是需要您在審查評論中包含此信息，但有時候提供更多解釋，對於表明您的意圖，您在遵循的最佳實踐，或爲您建議如何提高代碼健康狀況是十分恰當的。
給予指導
一般來說，修復 CL 是開發人員的責任，而不是審查者。 您無需爲開發人員詳細設計解決方案或編寫代碼。
但這並不意味着審查者應該沒有幫助。一般來說，您應該在指出問題和提供直接指導之間取得適當的平衡。指出問題並讓開發人員做出決定通常有助於開發人員學習，並使代碼審查變得更容易。它還可能產生更好的解決方案，因爲開發人員比審查者更接近代碼。
但是，有時直接說明，建議甚至代碼會更有幫助。代碼審查的主要目標是儘可能獲得最佳 CL。第二個目標是提高開發人員的技能，以便他們隨着時間的推移需要的審查越來越少。
接受解釋
如果您要求開發人員解釋一段您不理解的代碼，那通常會導致他們更清楚地重寫代碼。偶爾，在代碼中添加註釋也是一種恰當的響應，只要它不僅僅是解釋過於複雜的代碼。
僅在代碼審查工具中編寫的解釋對未來的代碼閱讀者沒有幫助。這僅在少數情況下是可接受的，例如當您查看一個您不熟悉的領域時，開發人員會用來向您解釋普通讀者已經知道的內容。