improve wording

api-design-principles-from-qt/README.md

@@ -91,7 +91,7 @@
 
 ## 1.4 符合直觉
 
-就像计算机里的其他事物一样，`API`应该符合直观。对于什么是符合直觉的什么不符合，不同的经验和背景的人对是否符合直觉有不同的看法。`API`符合直观的测试方法：经验不很丰富的用户不用阅读`API`文档就能搞懂`API`，而且程序员不用了解`API`就能看明白使用`API`的代码。
+就像计算机里的其他事物一样，`API`应该符合直观。对于什么是符合直觉的什么不符合，不同经验和背景的人对是否符合直觉会有不同的看法。`API`符合直观的测试方法：经验不很丰富的用户不用阅读`API`文档就能搞懂`API`，而且程序员不用了解`API`就能看明白使用`API`的代码。
 
 ## 1.5 易于记忆
 
@@ -160,7 +160,7 @@ regExp.setPattern(".");
 regExp.setPatternSyntax(Qt::WildcardSyntax);
 ```
 
-为实现这种类型的`API`，需要借助底层的对象的懒创建。例如，对于`QRegExp`的例子，在不知道模式语法（`pattern syntax`）的情况下，在`setPattern()`中去解释`"."`就为时过早了。
+为实现这种类型的`API`，需要借助底层对象的懒创建。例如，对于`QRegExp`的例子，在不知道模式语法（`pattern syntax`）的情况下，在`setPattern()`中去解释`"."`就为时过早了。
 
 属性之间常常有关联的；在这种情况下，我们必须小心处理。思考下面的问题：当前的风格（`style`）提供了『默认的图标尺寸』属性 vs. `QToolButton`的『`iconSize`』属性：
 
@@ -261,7 +261,7 @@ virtual void setOverwriteMode( bool b ) { overWrite = b; }
 
 `QTextEdit`从`Qt 3`移植到`Qt 4`的时候，几乎所有的虚函数都被移除了。有趣的是（但在预料之中），并没有人对此有大的抱怨，为什么？因为`Qt 3`没用到`QTextEdit`的多态行为 —— 只有你会；简单地说，没有理由去继承`QTextEdit`并重写这些函数，除非你自己调用了这些方法。如果在`Qt`在外部你的应用程序你需要多态，你可以自己添加多态。
 
-> 【译注】：『多态』的目的只不过是为了实践 —— 『依赖于接口而不是实现』，也就是说，接口是代码抽像的一个非常重要的方式（在`Java/Go`中都有专门的接口声明的语法）。所以，如果没有接口抽像，使用『多态』的意义也就不大了，因为也就没有必要使用『虚函数』了。
+> 【译注】：『多态』的目的只不过是为了实践 —— 『依赖于接口而不是实现』，也就是说，接口是代码抽像的一个非常重要的方式（在`Java/Go`中都有专门的接口声明语法）。所以，如果没有接口抽像，使用『多态』的意义也就不大了，因为也就没有必要使用『虚函数』了。
 
 ### 4.2.1 避免虚函数
 
@@ -470,7 +470,7 @@ widget->move(10, 10); // not const
 调用它的绘画行为必然会有副作用；
 它改变了它绘制所在设备的外观（及其所关联的状态）。鉴于这些，`paint()`作为`const`函数并不合理。
 进一步说，任何`paint()`或`QIcon`的`paint()`的视图函数是`const`函数也不合理。
-没有人会从内部的`const`函数去调用`QIcon::paint()`，除非他想显式的绕开`const`这个特性。
+没有人会从内部的`const`函数去调用`QIcon::paint()`，除非他想显式地绕开`const`这个特性。
 如果是这种情况，使用`const_cast`会更好。
 
 ```cpp
@@ -518,7 +518,7 @@ void QGraphicsItem::paint(QPainter *painter, const QStyleOptionGraphicsItem opti
 
 当你找不到好的命名时，写文档也是个很好方法：要做的就是尝试为各个条目（`item`）（如类、方法、枚举值等等）写文档，并用写下的第一句话作为启发。如果找不到一个确切的命名，往往说明这个条目是不该有的。如果所有尝试都失败了，并且你坚信这个概念是合理的，那么就发明一个新名字。像`widget`、`event`、`focus`和`buddy`这些命名就是在这一步诞生的。
 
-> 【译注】：写文档是一个非常好的习惯。写文档的过程其实就是在帮你梳理你的编程思路。很多时候，写着写文档你就会发现，你要去改代码去了。除了上述的好处多，写文档还有更多的好处。比如，在写文档的过程中，你发现文字描述过于复杂了，这表明着你的代码或逻辑是复杂的，这就倒逼你去重构你的代码。所以 —— **写文档其实就是写代码**。
+> 【译注】：写文档是一个非常好的习惯。写文档的过程其实就是在帮你梳理你的编程思路。很多时候，文档写着写着你就会发现要去改代码去了。除了上述的好处多，写文档还有更多的好处。比如，在写文档的过程中，你发现文字描述过于复杂了，这表明着你的代码或逻辑是复杂的，这就倒逼你去重构你的代码。所以 —— **写文档其实就是写代码**。
 
 ## 6.2 类的命名
 
@@ -554,7 +554,7 @@ tabWidget->setCornerWidget(widget, Qt::TopLeftCorner);
 str.indexOf("$(QTDIR)", Qt::CaseInsensitive);
 ```
 
-当对枚举值进行或运算并作为某种标志（`flag`）时，传统的做法是把或运算的结果保存在`int`型的值中，这不是类型安全的。`Qt 4`提供了一个模板类`QFlags<T>`，其中的`T`是枚举类型。为了方便使用，`Qt`用`typedef`重新定义了`QFlag`类型，所以可以用`Qt::Alignment`代替`QFlags<Qt::AlignmentFlag>`。
+当对枚举值进行或运算并作为某种标志（`flag`）时，传统的做法是把或运算的结果保存在`int`型的值中，但这不是类型安全的。`Qt 4`提供了一个模板类`QFlags<T>`，其中的`T`是枚举类型。为了方便使用，`Qt`用`typedef`重新定义了`QFlag`类型，所以可以用`Qt::Alignment`代替`QFlags<Qt::AlignmentFlag>`。
 
 习惯上，枚举类型命名用单数形式（因为它一次只能『持有』一个`flag`），而持有多个『`flag`』的类型用复数形式，例如：
 
@@ -606,7 +606,7 @@ typedef QFlags<AlignmentFlag> Alignment;
 
 ## 7.1 简化的陷阱
 
-一个常见的误解是：实现需要写的代码越少，`API`设计的越好。应该记住：代码只会写上几次，却要被反复阅读并理解。例如：
+一个常见的误解是：实现需要写的代码越少，`API`就设计得越好。应该记住：代码只会写上几次，却要被反复阅读并理解。例如：
 
 ```cpp
 QSlider *slider = new QSlider(12, 18, 3, 13, Qt::Vertical, 0, "volume");