詢問有關代碼的問題時

如果沒有提示別人應該從何入手，別要求他人幫你調試有問題的代碼。張貼幾百行的代碼，然後說一聲：它不能工作會讓你完全被忽略。只貼幾十行代碼，然後說一句：在第七行以後，我期待它顯示 <x>，但實際出現的是 <y>比較有可能讓你得到回應。

給出入口點

別人看你的代碼時，需要知道該從哪裡開始看、期望行為是什麼、實際行為是什麼。沒有這些信息，代碼越多，越像是在把排查工作整體轉交給別人。

一個更好的代碼問題通常包含：

• 最小可運行代碼片段。
• 運行方式或編譯命令。
• 預期輸出和實際輸出。
• 錯誤發生的位置。
• 你已經嘗試過的修改。

提供最小復現

最有效描述程序問題的方法是提供最精簡的 Bug 展示測試用例（bug-demonstrating test case）。什麼是最精簡的測試用例？那是問題的縮影；一小個程序片段能剛好展示出程序的異常行為，而不包含其他令人分散注意力的內容。怎麼製作最精簡的測試用例？如果你知道哪一行或哪一段代碼會造成異常的行為，複製下來並加入足夠重現這個狀況的代碼（例如，足以讓這段代碼能被編譯/直譯/被應用程序處理）。如果你無法將問題縮減到一個特定區塊，就複製一份代碼並移除不影響產生問題行為的部分。總之，測試用例越小越好（查看話不在多而在精一節）。

即使縮不小，也要展示努力

一般而言，要得到一段相當精簡的測試用例並不太容易，但永遠先嚐試這樣做是一個好習慣。這種方式可以幫助你瞭解如何自行解決這個問題 —— 而且即使你的嘗試不成功，黑客們也會看到你在嘗試取得答案的過程中付出了努力，這可以讓他們更願意與你合作。

如果你想要代碼審查

如果你只是想讓別人幫忙審查（Review）一下代碼，在信的開頭就要說出來，並且一定要提到你認為哪一部分特別需要關注以及為什麼。

“請幫我看看”太寬泛。更好的說法是：我想確認這個錯誤處理是否會吞掉異常，或者 這段鎖的使用是否可能導致死鎖。明確審查目標，別人才能有效投入。