优化各章节的翻译 (#8)

* simplfy 'in the third case' translation

* make translate smoother

* 修改 '二进制搜索'为'二分查找'

* 修改 '评论'->'注释'

* 停止对变量名称 block 翻译，优化不够专业的描述

* 解决部分生硬的翻译

* 优化‘Names should be precise’ 的翻译

* 优化 14 章剩余的翻译

* 优化 15 章的翻译

* 优化 16 章的翻译

* 优化 17 章的翻译

* 优化第 18 章的翻译

* 优化第 19 章的翻译

* 优化第 20 章前 3 节的翻译

* 优化 20 章剩余部分的翻译

* 优化 21 章的翻译

* 修改 READEME 中的翻译错误

* 同步修改翻译标题

* 更新 README 中的错误翻译

* 更新 README 中的错误翻译

README.md

@@ -27,10 +27,10 @@
 - [第 9 章 在一起更好还是分开更好？](docs/ch09.md)
 - [第 10 章 定义不存在的错误](docs/ch10.md)
 - [第 11 章 设计它两次](docs/ch11.md)
-- [第 12 章 为什么写评论呢？四个理由](docs/ch12.md)
+- [第 12 章 为什么要写注释呢？有四个理由](docs/ch12.md)
 - [第 13 章 注释应该描述代码中不明显的内容](docs/ch13.md)
 - [第 14 章 选择的名字](docs/ch14.md)
-- [第 15 章 先写评论](docs/ch15.md)
+- [第 15 章 先写注释](docs/ch15.md)
 - [第 16 章 修改现有的代码](docs/ch16.md)
 - [第 17 章 一致性](docs/ch17.md)
 - [第 18 章 代码应该是显而易见的](docs/ch18.md)

docs/README.md

@@ -16,10 +16,10 @@
 - [第 9 章 在一起更好还是分开更好？](ch09.md)
 - [第 10 章 定义不存在的错误](ch10.md)
 - [第 11 章 设计它两次](ch11.md)
-- [第 12 章 为什么写评论呢？四个理由](ch12.md)
+- [第 12 章 为什么要写注释？有四个理由](ch12.md)
 - [第 13 章 注释应该描述代码中不明显的内容](ch13.md)
 - [第 14 章 选择的名字](ch14.md)
-- [第 15 章 先写评论](ch15.md)
+- [第 15 章 先写注释](ch15.md)
 - [第 16 章 修改现有的代码](ch16.md)
 - [第 17 章 一致性](ch17.md)
 - [第 18 章 代码应该是显而易见的](ch18.md)

docs/ch12.md

@@ -1,4 +1,4 @@
-# 第 12 章 为什么写注释？四个理由
+# 第 12 章 为什么要写注释？有四个理由
 
 > Chapter 12 Why Write Comments? The Four Excuses
 

docs/ch13.md

@@ -94,7 +94,7 @@ caretMemX  = null;
 
 > None of these comments provide any value. For the first two comments, the code is already clear enough that it doesn’t really need comments; in the third case, a comment might be useful, but the current comment doesn’t provide enough detail to be helpful.
 
-这些注释均未提供任何价值。对于前两个注释，代码已经很清楚了，它实际上不需要注释。在第三种情况下，注释可能有用，但是当前注释没有提供足够的细节来提供帮助。
+这些注释均未提供任何价值。对于前两个注释，代码已经很清楚了，它实际上不需要注释。第三个注释可能有用，但是当前注释没有提供足够的细节来提供帮助。
 
 > After you have written a comment, ask yourself the following question: could someone who has never seen the code write the comment just by looking at the code next to the comment? If the answer is yes, as in the examples above, then the comment doesn’t make the code any easier to understand. Comments like these are why some people think that comments are worthless.
 
@@ -122,7 +122,7 @@ private static final int textHorizontalPadding = 4;
 
 > These comments just take the words from the method or variable name, perhaps add a few words from argument names and types, and form them into a sentence. For example, the only thing in the second comment that isn’t in the code is the word “to”! Once again, these comments could be written just by looking at the declarations, without any understanding the methods of variables; as a result, they have no value.
 
-这些注释只是从方法或变量名中提取单词，或者从参数名称和类型中添加几个单词，然后将它们组成一个句子。例如，第二个注释中唯一不在代码中的是单词“ to”！再说一次，这些注释可以仅通过查看声明来编写，而无需任何了解变量的方法。结果，它们没有价值。
+这些注释只是从方法或变量名中提取单词，或者从参数名称和类型中添加几个单词，然后将它们组成一个句子。例如，第二个注释中唯一不在代码中的是单词“ to”！再说一次，这些注释可以仅通过查看声明来编写，而无需任何了解变量的方法，所以它们没有价值。
 
 > img Red Flag: Comment Repeats Code img
 
@@ -364,7 +364,7 @@ public class Http {...}
 - 注释必须描述每个参数和返回值（如果有）。这些注释必须非常精确，并且必须描述对参数值的任何约束以及参数之间的依赖关系。
 - 如果该方法有任何副作用，则必须在接口注释中记录这些副作用。副作用是该方法的任何结果都会影响系统的未来行为，但不属于结果的一部分。例如，如果该方法将一个值添加到内部数据结构中，可以通过将来的方法调用来检索该值，则这是副作用。写入文件系统也是一个副作用。
 - 方法的接口注释必须描述该方法可能产生的任何异常。
-- 如果在调用某个方法之前必须满足任何前提条件，则必须对其进行描述（也许必须先调用其他方法；对于二进制搜索方法，必须对要搜索的列表进行排序）。尽量减少前提条件是一个好主意，但是任何保留的条件都必须记录在案。
+- 如果在调用某个方法之前必须满足任何前提条件，则必须对其进行描述（也许必须先调用其他方法；对于二分查找方法，必须对要搜索的列表进行排序）。尽量减少前提条件是一个好主意，但是任何保留的条件都必须记录在案。
 
 > Here is the interface comment for a method that copies data out of a Buffer object:
 
@@ -486,7 +486,7 @@ while  (true) {
 ---
 
 - 第一段的大部分与实现有关，而不是接口。举一个例子，用户不需要知道用于与服务器通信的特定远程过程调用的名称。在第一段的后半部分中提到的配置参数都是所有私有变量，它们仅与类的维护者相关，而与类的用户无关。所有这些实现信息都应从注释中省略。
-- 该评论还包括一些显而易见的事情。例如，不需要告诉用户包括 IndexLookup.h：任何编写 C++ 代码的人都可以猜测这是必要的。另外，“通过提供所有必要的信息”一词无语，因此可以省略。
+- 该注释还包括一些显而易见的事情。例如，不需要告诉用户包括 IndexLookup.h：任何编写 C++ 代码的人都可以猜测这是必要的。另外，“通过提供所有必要的信息”一词无语，因此可以省略。
 
 > A shorter comment for this class is sufficient (and preferable):