养成良好的编程风格

Posted 2022-05-10 小杰编程

类

类是 C++ 中代码的基本单元. 显然, 它们被广泛使用. 本节列举了在写一个类时的主要注意事项.

构造函数的职责

总述

不要在构造函数中调用虚函数, 也不要在无法报出错误时进行可能失败的初始化.

定义

在构造函数中可以进行各种初始化操作。

优点

• 无需考虑类是否被初始化.
• 经过构造函数完全初始化后的对象可以为​​const​​ 类型, 也能更方便地被标准容器或算法使用.

缺点

• 如果在构造函数内调用了自身的虚函数, 这类调用是不会重定向到子类的虚函数实现. 即使当前没有子类化实现, 将来仍是隐患.
• 在没有使程序崩溃 (因为并不是一个始终合适的方法) 或者使用异常 (因为已经被​​禁用​​ 等方法的条件下, 构造函数很难上报错误
• 如果执行失败, 会得到一个初始化失败的对象, 这个对象有可能进入不正常的状态, 必须使用​​bool IsValid()​​ 或类似这样的机制才能检查出来, 然而这是一个十分容易被疏忽的方法.
• 构造函数的地址是无法被取得的, 因此, 举例来说, 由构造函数完成的工作是无法以简单的方式交给其他线程的.

结论

构造函数不允许调用虚函数. 如果代码允许, 直接终止程序是一个合适的处理错误的方式. 否则, 考虑用 ​​Init()​​ 方法或工厂函数.

构造函数不得调用虚函数, 或尝试报告一个非致命错误. 如果对象需要进行有意义的 (non-trivial) 初始化, 考虑使用明确的 Init() 方法或使用工厂模式. Avoid ​​Init()​​ methods on objects with no other states that affect which public methods may be called (此类形式的半构造对象有时无法正确工作).

隐式类型转换

总述

不要定义隐式类型转换. 对于转换运算符和单参数构造函数, 请使用 ​​explicit​​ 关键字

定义

隐式类型转换允许一个某种类型 (称作 *源类型*) 的对象被用于需要另一种类型 (称作 *目的类型*) 的位置, 例如, 将一个 ​​int​​ 类型的参数传递给需要 ​​double​​ 类型的函数.

除了语言所定义的隐式类型转换, 用户还可以通过在类定义中添加合适的成员定义自己需要的转换. 在源类型中定义隐式类型转换, 可以通过目的类型名的类型转换运算符实现 (例如 ​​operator bool()​​). 在目的类型中定义隐式类型转换, 则通过以源类型作为其唯一参数 (或唯一无默认值的参数) 的构造函数实现.

​​explicit​​ 关键字可以用于构造函数或 (在 C++11 引入) 类型转换运算符, 以保证只有当目的类型在调用点被显式写明时才能进行类型转换, 例如使用 ​​cast​​. 这不仅作用于隐式类型转换, 还能作用于 C++11 的列表初始化语法:

class Foo 
  explicit Foo(int x, double y);
  ...
;

void Func(Foo f);

此时下面的代码是不允许的:

Func(42, 3.14);  // Error

这一代码从技术上说并非隐式类型转换, 但是语言标准认为这是 ​​explicit​​ 应当限制的行为.

优点

• 有时目的类型名是一目了然的, 通过避免显式地写出类型名, 隐式类型转换可以让一个类型的可用性和表达性更强.
• 隐式类型转换可以简单地取代函数重载.
• 在初始化对象时, 列表初始化语法是一种简洁明了的写法.

缺点

• 隐式类型转换会隐藏类型不匹配的错误. 有时, 目的类型并不符合用户的期望, 甚至用户根本没有意识到发生了类型转换.
• 隐式类型转换会让代码难以阅读, 尤其是在有函数重载的时候, 因为这时很难判断到底是哪个函数被调用.
• 单参数构造函数有可能会被无意地用作隐式类型转换.
• 如果单参数构造函数没有加上​​explicit​​ 关键字, 读者无法判断这一函数究竟是要作为隐式类型转换, 还是作者忘了加上​​explicit​​ 标记.
• 并没有明确的方法用来判断哪个类应该提供类型转换, 这会使得代码变得含糊不清.
• 如果目的类型是隐式指定的, 那么列表初始化会出现和隐式类型转换一样的问题, 尤其是在列表中只有一个元素的时候.

结论

在类型定义中, 类型转换运算符和单参数构造函数都应当用 ​​explicit​​ 进行标记. 一个例外是, 拷贝和移动构造函数不应当被标记为 ​​explicit​​, 因为它们并不执行类型转换. 对于设计目的就是用于对其他类型进行透明包装的类来说, 隐式类型转换有时是必要且合适的. 这时应当联系项目组长并说明特殊情况.

不能以一个参数进行调用的构造函数不应当加上 ​​explicit​​. 接受一个 ​​std::initializer_list​​ 作为参数的构造函数也应当省略 ​​explicit​​, 以便支持拷贝初始化 (例如 ​​MyType m = 1, 2;​​).

可拷贝类型和可移动类型

总述

如果你的类型需要, 就让它们支持拷贝 / 移动. 否则, 就把隐式产生的拷贝和移动函数禁用.

定义

可拷贝类型允许对象在初始化时得到来自相同类型的另一对象的值, 或在赋值时被赋予相同类型的另一对象的值, 同时不改变源对象的值. 对于用户定义的类型, 拷贝操作一般通过拷贝构造函数与拷贝赋值操作符定义. ​​string​​ 类型就是一个可拷贝类型的例子.

可移动类型允许对象在初始化时得到来自相同类型的临时对象的值, 或在赋值时被赋予相同类型的临时对象的值 (因此所有可拷贝对象也是可移动的). ​​std::unique_ptr<int>​​ 就是一个可移动但不可复制的对象的例子. 对于用户定义的类型, 移动操作一般是通过移动构造函数和移动赋值操作符实现的.

拷贝 / 移动构造函数在某些情况下会被编译器隐式调用. 例如, 通过传值的方式传递对象.

优点

可移动及可拷贝类型的对象可以通过传值的方式进行传递或者返回, 这使得 API 更简单, 更安全也更通用. 与传指针和引用不同, 这样的传递不会造成所有权, 生命周期, 可变性等方面的混乱, 也就没必要在协议中予以明确. 这同时也防止了客户端与实现在非作用域内的交互, 使得它们更容易被理解与维护. 这样的对象可以和需要传值操作的通用 API 一起使用, 例如大多数容器.
拷贝 / 移动构造函数与赋值操作一般来说要比它们的各种替代方案, 比如 ​​Clone()​​, ​​CopyFrom()​​ or ​​Swap()​​, 更容易定义, 因为它们能通过编译器产生, 无论是隐式的还是通过 ​​= default​​. 这种方式很简洁, 也保证所有数据成员都会被复制. 拷贝与移动构造函数一般也更高效, 因为它们不需要堆的分配或者是单独的初始化和赋值步骤, 同时, 对于类似 ​​省略不必要的拷贝​​ 这样的优化它们也更加合适.

移动操作允许隐式且高效地将源数据转移出右值对象. 这有时能让代码风格更加清晰.

缺点

许多类型都不需要拷贝, 为它们提供拷贝操作会让人迷惑, 也显得荒谬而不合理. 单件类型 (​​Registerer​​), 与特定的作用域相关的类型 (​​Cleanup​​), 与其他对象实体紧耦合的类型 (​​Mutex​​) 从逻辑上来说都不应该提供拷贝操作. 为基类提供拷贝 / 赋值操作是有害的, 因为在使用它们时会造成 ​​对象切割​​ . 默认的或者随意的拷贝操作实现可能是不正确的, 这往往导致令人困惑并且难以诊断出的错误.

拷贝构造函数是隐式调用的, 也就是说, 这些调用很容易被忽略. 这会让人迷惑, 尤其是对那些所用的语言约定或强制要求传引用的程序员来说更是如此. 同时, 这从一定程度上说会鼓励过度拷贝, 从而导致性能上的问题.

结论

如果需要就让你的类型可拷贝 / 可移动. 作为一个经验法则, 如果对于你的用户来说这个拷贝操作不是一眼就能看出来的, 那就不要把类型设置为可拷贝. 如果让类型可拷贝, 一定要同时给出拷贝构造函数和赋值操作的定义, 反之亦然. 如果让类型可移动, 同时移动操作的效率高于拷贝操作, 那么就把移动的两个操作 (移动构造函数和赋值操作) 也给出定义. 如果类型不可拷贝, 但是移动操作的正确性对用户显然可见, 那么把这个类型设置为只可移动并定义移动的两个操作.
如果定义了拷贝/移动操作, 则要保证这些操作的默认实现是正确的. 记得时刻检查默认操作的正确性, 并且在文档中说明类是可拷贝的且/或可移动的.

class Foo 
 public:
  Foo(Foo&& other) : field_(other.field) 
  // 差, 只定义了移动构造函数, 而没有定义对应的赋值运算符.

 private:
  Field field_;
;

由于存在对象切割的风险, 不要为任何有可能有派生类的对象提供赋值操作或者拷贝 / 移动构造函数 (当然也不要继承有这样的成员函数的类). 如果你的基类需要可复制属性, 请提供一个 ​​public virtual Clone()​​ 和一个 ​​protected​​ 的拷贝构造函数以供派生类实现.

如果你的类不需要拷贝 / 移动操作, 请显式地通过在 ​​public​​ 域中使用 ​​= delete​​ 或其他手段禁用之.

// MyClass is neither copyable nor movable.
MyClass(const MyClass&) = delete;
MyClass& operator=(const MyClass&) = delete;

结构体 VS. 类

总述

仅当只有数据成员时使用 ​​struct​​, 其它一概使用 ​​class​​.

说明

在 C++ 中 ​​struct​​ 和 ​​class​​ 关键字几乎含义一样. 我们为这两个关键字添加我们自己的语义理解, 以便为定义的数据类型选择合适的关键字.

​​struct​​ 用来定义包含数据的被动式对象, 也可以包含相关的常量, 但除了存取数据成员之外, 没有别的函数功能. 并且存取功能是通过直接访问位域, 而非函数调用. 除了构造函数, 析构函数, ​​Initialize()​​, ​​Reset()​​, ​​Validate()​​ 等类似的用于设定数据成员的函数外, 不能提供其它功能的函数.

如果需要更多的函数功能, ​​class​​ 更适合. 如果拿不准, 就用 ​​class​​.

为了和 STL 保持一致, 对于仿函数等特性可以不用 ​​class​​ 而是使用 ​​struct​​.

注意: 类和结构体的成员变量使用不同的命名规则.

继承

总述

使用组合 (YuleFox 注: 这一点也是 GoF 在 <<Design Patterns>> 里反复强调的) 常常比使用继承更合理. 如果使用继承的话, 定义为 ​​public​​ 继承.

定义

当子类继承基类时, 子类包含了父基类所有数据及操作的定义. C++ 实践中, 继承主要用于两种场合: 实现继承, 子类继承父类的实现代码; ​​接口继承​​, 子类仅继承父类的方法名称.

优点

实现继承通过原封不动的复用基类代码减少了代码量. 由于继承是在编译时声明, 程序员和编译器都可以理解相应操作并发现错误. 从编程角度而言, 接口继承是用来强制类输出特定的 API. 在类没有实现 API 中某个必须的方法时, 编译器同样会发现并报告错误.

缺点

对于实现继承, 由于子类的实现代码散布在父类和子类间之间, 要理解其实现变得更加困难. 子类不能重写父类的非虚函数, 当然也就不能修改其实现. 基类也可能定义了一些数据成员, 因此还必须区分基类的实际布局.

结论

所有继承必须是 ​​public​​ 的. 如果你想使用私有继承, 你应该替换成把基类的实例作为成员对象的方式.

不要过度使用实现继承. 组合常常更合适一些. 尽量做到只在 “是一个” (“is-a”, YuleFox 注: 其他 “has-a” 情况下请使用组合) 的情况下使用继承: 如果 ​​Bar​​ 的确 “是一种” ​​Foo​​, ​​Bar​​ 才能继承 ​​Foo​​.

必要的话, 析构函数声明为 ​​virtual​​. 如果你的类有虚函数, 则析构函数也应该为虚函数.

对于可能被子类访问的成员函数, 不要过度使用 ​​protected​​ 关键字. 注意, 数据成员都必须是 ​​私有的​​.

对于重载的虚函数或虚析构函数, 使用 ​​override​​, 或 (较不常用的) ​​final​​ 关键字显式地进行标记. 较早 (早于 C++11) 的代码可能会使用 ​​virtual​​ 关键字作为不得已的选项. 因此, 在声明重载时, 请使用 ​​override​​, ​​final​​ 或 ​​virtual​​ 的其中之一进行标记. 标记为 ​​override​​ 或 ​​final​​ 的析构函数如果不是对基类虚函数的重载的话, 编译会报错, 这有助于捕获常见的错误. 这些标记起到了文档的作用, 因为如果省略这些关键字, 代码阅读者不得不检查所有父类, 以判断该函数是否是虚函数.