Virtools的VSL和SDK编程编码规则

同宏函数相比，内联函数不但具有宏函数的效率，而且使用起来更安全。

2.6.8 如果重载了操作符\，也应该重载操作符 \

该规则参考自《Effective C++》中的条款10。

规范级别：规则 规则描述：

如果你为一个类重载了操作符new，那你也应该为这个类重载操作符delete。 理由：

操作符new和操作符delete需要一起合作。 2.6.9 类数据成员的访问控制

规范级别：规则 规则描述：

类对外的接口应该是完全功能化的，类中可以定义Public的成员函数，但不应该有Public的数据成员。 理由：

要想改变对象的当前状态，应该通过它的成员函数来实现，而不应该通过直接设置它的数据成员这种方法。一个类的数据成员应该声明为private的，最起码也应该是protected的。

2.6.10限制类继承的层数

规范级别：建议 规则描述：

当继承的层数超过5层时，问题就很严重了，需要有特别的理由和解释。

理由：

●很深的继承通常意味着未做通盘的考虑； ●会显著降低效率；

●可以尝试用类的组合代替过多的继承；

●与此类似，同层类的个数也不能太多，否则应该考虑是否要增加一个父类，以便做某种程度

上的新的抽象，从而减少同层类的个数。

2.6.11慎用多继承

规范级别：建议 规则描述：

C++提供多继承的机制。多继承在描述某些事物时可能是非常有利的，甚至是必须

的，但我们在使用多继承的时，一定要慎重，在决定使用多继承时，确实要有非常充分的理由。 理由：

多继承会显著增加代码的复杂性，还会带来潜在的混淆。比如在很多C++书籍中提

到的菱形继承问题，如下图所示：

图2-1 菱形继承

A派生子类B、C，D多继承于B、C。这种情况下，会导致类D的对象中有两个类A

子对象。

2.6.12考虑类的复用

规范级别：建议

规则描述：类设计的同时，考虑类的可复用性。

2.7程序组织

对程序组织的要求。

2.7.1 一个头文件中只声明一个类

规范级别：规则 规则描述：

在一个头文件中，只应该包含对一个类的声明（嵌套类的情况除外）。头文件是指以.h、.hh、.H、.hxx、.hpp为后缀的文件。 理由：提高代码的可读性。 2.7.2 一个源文件中只实现一个类

规范级别：规则 规则描述:

在一个源文件中定义的每一个函数，都应该属于同一个类，即对一个类的实现描述要独占一个文件。源文件指以*.cc, *.cxx, *.cpp, *.C or *.c为后缀的代码文件。 理由：提高代码的可读性。

2.7.3 头文件中只包含声明，不应包含定义

规范级别：规则 规则描述：

在头文件中只包含声明，不要包含全局变量和函数的定义。头文件指以.h、 .hh、.H、 .hxx、.hpp为后缀的代码文件。

内联函数的情况除外。

理由：在头文件中只应该包含各种声明，而不应该包含具体的实现。 2.7.4 源文件中不要有类的声明

规范级别：规则 规则描述:

在源文件中只应该包含对类的实现，不应该包含任何类的声明。类声明应该统一放到头文件中去。源文件指以*.cc, *.cxx, *.cpp, *.C or *.c为后缀的代码文件。 理由：提高代码的可读性。 2.7.5 可被包含的文件

规范级别：规则

规则描述：只允许头文件被包含到其它的代码文件中去。

理由：改善程序代码的组织结构。 2.7.6 避免头文件的重复包含

规范级别：规则 规则描述：

头文件的格式应该类似于：

#ifndef #define ... ... #endif 或者

#if !defined () #define ... ... #endif

上面的是一个标识字符串，要求该标识字符串必须唯一。建议使用该文件的答谢文件名。 理由：

避免对同一头文件的重复包含。

举例:

// 对于文件audit.h，它的文件结构应该为： #ifndef AUDIT_H #define AUDIT_H ... ... #endif