Merge pull request #168 from Ayx03/patch-3

Close #162、#163、#164

README-zh_CN.md

@@ -372,11 +372,11 @@ Stack Exchange 已经成长到[超过一百个网站](https://stackexchange.com/
 
 要理解专家们所处的世界，请把专业技能想像为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
 
-所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问`我想更好地理解 X，可否指点一下哪有好一点说明？`通常比问`你能解释一下 X 吗？`更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
+所以，界定一下你的问题，使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你获得有用的答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此，问`我想更好地理解 X，可否指点一下哪有好一点说明？`通常比问`你能解释一下 X 吗？`更好。如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
 
 ### 询问有关代码的问题时
 
-别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：`它不能工作`会让你完全被忽略。只贴几十行代码，然后说一句：`在第七行以后，我期待它显示 <x>，但实际出现的是 <y>`比较有可能让你得到回应。
+如果没有提示别人应该从何入手，别要求他人帮你调试有问题的代码。张贴几百行的代码，然后说一声：`它不能工作`会让你完全被忽略。只贴几十行代码，然后说一句：`在第七行以后，我期待它显示 <x>，但实际出现的是 <y>`比较有可能让你得到回应。
 
 最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能**刚好**展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好（查看[话不在多而在精](#话不在多而在精)一节）。
 
@@ -424,7 +424,7 @@ Stack Exchange 已经成长到[超过一百个网站](https://stackexchange.com/
 
 问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。
 
-最理想的方式是向最初提问的话题回复此消息，并在标题中包含`已修正`，`已解决`或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串`问题 X`和`问题 X - 已解决`的潜在回复者就明白不用再浪费时间了（除非他个人觉得`问题 X`的有趣），因此可以利用此时间去解决其它问题。
+最理想的方式是向最初提问的话题回复此消息，并在标题中包含`已修正`，`已解决`或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串`问题 X`和`问题 X - 已解决`的潜在回复者就明白不用再浪费时间了（除非他个人觉得`问题 X`有趣），因此可以利用此时间去解决其它问题。
 
 补充说明不必很长或是很深入；简单的一句`你好，原来是网线出了问题！谢谢大家 – Bill`比什么也不说要来的好。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。
 

README.md

@@ -373,11 +373,11 @@ Stack Exchange 已經成長到[超過一百個網站](http://stackexchange.com/s
 
 要理解專家們所處的世界，請把專業技能想像為充裕的資源，而回覆的時間則是稀缺的資源。你要求他們奉獻的時間越少，你越有可能從真正專業而且很忙的專家那裡得到解答。
 
-所以，界定一下你的問題，使專家花在辨識你的問題和回答所需要付出的時間減到最少，這技巧對你有用答案相當有幫助──但這技巧通常和簡化問題有所區別。因此，問```我想更好的理解X，可否指點一下哪裡有好一點的說明？```通常比問```你能解釋一下X嗎？```更好。如果你的程式碼不能運作，通常請別人看看哪裡有問題，比要求別人替你改正要明智得多。
+所以，界定一下你的問題，使專家花在辨識你的問題和回答所需要付出的時間減到最少，這技巧對你獲得有用的答案相當有幫助──但這技巧通常和簡化問題有所區別。因此，問```我想更好的理解X，可否指點一下哪裡有好一點的說明？```通常比問```你能解釋一下X嗎？```更好。如果你的程式碼不能運作，通常請別人看看哪裡有問題，比要求別人替你改正要明智得多。
 
 ### 詢問有關程式碼的問題時
 
-別要求他人幫你有問題的程式碼除錯而不提示一下應該從何入手。張貼幾百行的程式碼，然後說一聲：```它不會動```會讓你完全被忽略。只貼幾十行程式碼，然後說一句：```在第七行以後，我期待它顯示 <x>，但實際出現的是 <y>```比較有可能讓你得到回應。
+如果沒有提示別人應該從何入手，別要求他人幫你調試有問題的程式碼。張貼幾百行的程式碼，然後說一聲：```它不會動```會讓你完全被忽略。只貼幾十行程式碼，然後說一句：```在第七行以後，我期待它顯示 <x>，但實際出現的是 <y>```比較有可能讓你得到回應。
 
 最有效描述程式問題的方法是提供最精簡的臭蟲展示測試示例（bug-demonstrating test case）。什麼是最精簡的測試示例? 那是問題的縮影；一小個程式片段能**剛好**展示出程式的異常行為，而不包含其他令人分散注意力的內容。怎麼製作最精簡的測試示例？如果你知道哪一行或哪一段程式碼會造成異常的行為，複製下來並加入足夠重現這個狀況的程式碼（例如，足以讓這段程式碼能被編譯/直譯/被應用程式處理）。如果你無法將問題縮減到一個特定區塊，就複製一份程式碼並移除不影響產生問題行為的部分。總之，測試示例越小越好（查看[話不在多而在精](#話不在多而在精)一節）。
 
@@ -425,7 +425,7 @@ Stack Exchange 已經成長到[超過一百個網站](http://stackexchange.com/s
 
 問題解決後，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注，應該在那裡貼一個說明比較恰當。
 
-最理想的方式是向最初提問的話題回覆此消息，並在標題中包含```已修正```，```已解決```或其它同等含義的明顯標記。在人來人往的郵件列表裡，一個看見討論串```問題 X```和```問題的X - 已解決```的潛在回覆者就明白不用再浪費時間了（除非他個人覺得```問題 X```的有趣），因此可以利用此時間去解決其它問題。
+最理想的方式是向最初提問的話題回覆此消息，並在標題中包含```已修正```，```已解決```或其它同等含義的明顯標記。在人來人往的郵件列表裡，一個看見討論串```問題 X```和```問題的X - 已解決```的潛在回覆者就明白不用再浪費時間了（除非他個人覺得```問題 X```有趣），因此可以利用此時間去解決其它問題。
 
 補充說明不必很長或是很深入；簡單的一句```你好，原來是網路線出了問題！謝謝大家 – Bill```比什麼也不說要來的好。事實上，除非結論真的很有技術含量，否則簡短可愛的小結比長篇大論更好。說明問題是怎樣解決的，但大可不必將解決問題的過程複述一遍。