C++之父Bjarne Stroustrup对C++使用者的忠告
C++之父Bjarne Stroustrup 写的The C++ Programming Language (Special Edition) 中各章后
面的忠告。
第1 章致读者
[1] 在编写程序时，你是在为你针对某个问题的解决方案中的思想建立起一种具体表示。让程序的结构尽可能地直接反映这些思想。
[a] 如果你能把“它”看成一个独立的概念，就把它做成一个类。
[b] 如果你能把“它”看成一个独立地实体，就把它做成某个类的一个对象。
[c] 如果两个类有共同的界面，将此界面做成一个抽象类。
[d] 如果两个类的实现有某些显著的共同东西，静这些共性做成一个基类。
[e] 如果一个类是一种对象的容器，将它做成一个模板。
[f] 如果一个函数实现对某容器的一个算法，将它实现为对一族容器可用的模板函数。
[g] 如果一组类、模板等互相之间有逻辑关系，将它们放进一个名字空间力。
[2] 在你定义一个并不是实现某个像矩阵或复数这样的数学对象的类时，或者定义一个低层的类型如链表的时候：
[a] 不要使用全局数据（使用成员）。
[b] 不要使用全局函数。
[c] 不要使用公用数据成员。
[d] 不要使用友元，除非为了避免[a]或[c]。
[e] 不要在一个类里面放“类型域”；采用虚函数。
[f] 不要使用内联函数，除非作为效果显著的优化。
第2 章C++概览
[1] 不用害怕，一切都会随着时间的推移而逐渐明朗起来。
[2] 你并不需要在知道了C++地所有细节之后才能写出好的C++程序。
[3] 请特别关注程序设计技术，而不是各种语言特征。
第3 章标准库概念
[1] 不要像重新发明车轮那样企图做每件事；去使用库。
[2] 不要相信奇迹；要理解你的库能做什么，它们如何做，它们做时需要多大代价。
[3] 当你遇到一个选择时，应该优先选择标准库而不是其他的库。
[4] 不要认为标准库对于任何事情都是最理想的。
[5] 切记#include 你所用到的功能的头文件。
[6] 记住，标准库的功能定义在名字空间std 中。
[7] 请用string，而不是char*。
[8] 如果怀疑，就用一个检查区间范围的向量。
[9] vector<T>、list<T>和map<key, value>都比T[]好。
[10] 如果要向一个容器中添加一个元素，用push_back()或back_insert()。
[11] 采用对vector 的push_back()，而不是realloc()。
[12] 在main()中捕捉公共的异常。
第4 章类型和声明
[1] 保持较小的作用域。
[2] 不要在一个作用域和它外围的作用域里采用同样的名字。
[3] 在一个声明中（只）声明一个名字。
[4] 让常用的和局部的名字比较短，让不常用的和全局的名字比较长。
[5] 避免看起来类似的名字。
[6] 维持某种统一的命名风格。
[7] 仔细选择名字，反映其意义而不是反映实现方式。
[8] 如果所用的内部类型表示某种可能变化的值，请用typdef 为它定义一个有意义的名字。
[9] 用typedef 为类型定义同义词，用枚举或类去定义新类型。
[10] 切记每个声明中都必须描述一个类型（没有隐式的int ）。
[11] 避免有关字符值的不必要的假设。
[12] 避免有关整数大小的不必要假设。
[13] 避免有关浮点类型表示范围的不必要假设。
[14] 优先使用普通的int 而不是short int 或者long int 。
[15] 优先使用double 而不是float 或者long double。
[16] 优先使用普通的char 而不是signed char 或者unsigned char。
[17] 避免做出有关对象大小的不必要假设。
[18] 避免无符号算术。
[19] 应该带着疑问去看待从signed 到unsigned，或者从unsigned 到singed 的转换。
[20] 应该带着疑问去看待从浮点到整数的转换。
[21] 应该带着疑问其看待向较小类型的转换，如将int 转换到char。
第5 章指针、数组和结构
[1] 避免非平凡的指针算术。
[2] 当心，不要超出函数的界限去写。
[3] 尽量使用0 而不是NULL。
[4] 尽量使用vector 和valarrray 而不是内部（C 风格）的数组。
[5] 尽量使用string 而不是以0 结尾的char 数组。
[6] 尽量少使用普通的引用参数。
[7] 避免void*，除了在某些低级代理。
[8] 避免在代码中使用非平凡的文字量（“神秘的数”）。相反，应该定义和使用各种符号常量。
第6 章表达式和语句
[1] 应尽量可能使用标准库，而不是其他的库和“手工打造的代码”。
[2] 避免过于复杂的表达式。
[3] 如果对运算符的优先级有疑问，加括号。
[4] 避免显式类型转换。
[5] 若必须做显式类型转换，提倡使用特殊强制运算符，而不是C 风格的强制。
[6] 只对定义良好的构造使用T(e)记法。
[7] 避免带有无定义求值顺序的表达式。
[8] 避免goto。
[9] 避免do 语句。
[10] 在你已经有了去初始化某个变量的值之前，不要去声明它。
[11] 式注释简洁、清晰、有意义。
[12] 保持一致的缩进编排风格。
[13] 倾向于去定义一个成员函数operator new()去取代全局的operator new()。
[14] 在读输入的时候，总应考虑病态形式的输入。
第7 章函数
[1] 质疑那些非const 的引用参数；如果你想要一个函数去修改其参数，请使用指针或者返回值。
[2] 当你需要尽可能减少参数复制时，应该使用const 引用参数。
[3] 广泛而一致地使用const。
[4] 避免宏。
[5] 避免不确定数目的参数。
[6] 不要返回局部变量的指针或者引用。
[7] 当一些函数对不同的类型执行概念上相同的工作时，请使用重载。
[8] 在各种整数上重载时，通过提供函数去消除常见的歧义性。
[9] 在考虑使用指向函数的指针时，请考虑虚函数或模板是不是更好的选择。
[10] 如果你必须使用宏，请使用带有许多大写字母的丑陋的名字。
第8 章名字空间和异常
[1] 用名字空间表示逻辑结构。
[2] 将每个非局部的名字放入某个名字空间里，除了main()之外。
[3] 名字空间的设计应该让你能很方便地使用它，而又不会意外地访问了其他的无关名字空间。
[4] 避免对名字空间使用很短的名字。
[5] 如果需要，通过名字空间别名去缓和和长名字空间的影响。
[6] 避免给你的名字空间的用户添加太大的记法负担。
[7] 在定义名字空间的成员时使用namespace::member 的形式。
[8] 只在转换时，或者在局部作用域里，才用using namespace。
[9] 利用异常去松弛“错误”处理代码和正常处理代码之间的联系。
[10] 采用用户定义类型作为异常，不用内部类型。
[11] 当局部控制结构足以应付问题，不要使用异常。
第9 章源文件和程序
[1] 利用头文件去表示界面和强调逻辑结构。
[2] 用#include 将头文件包含到实现有关功能的源文件里。
[3] 不要在不同编译单位里定义具有同样名字，意义类似但又不同的全局变量。
[4] 避免在头文件里定义非inline 函数。
[5] 只在全局作用域或名字空间里使用#include。
[6] 只用#include 包含完整的定义。
[7] 使用包含保护符。
[8] 用#include 将C 头文件包含到名字空间里，以避免全局名字。
[9] 将头文件做成自给自足的。
[10] 区分用户界面和实现界面。
[11] 区分一般用户界面和专家用户界面。
[12] 在有意向用于非C++程序组成部分的代码中，应避免需要运行时初始化的非局部对象。
第10 章类
[1] 用类表示概念。
[2] 只将public 数据（struct）用在它实际杀过那仅仅时数据，而且对于这些数据成员并不存在不变式的地方。
[3] 一个具体类型属于最简单的类。如果有用的话，就应该尽可能使用具体类型，而不要采用更复杂的，也不要用简单的数据结构。
[4] 只将那些需要直接访问类的表示的函数作为成员函数。
[5] 采用名字空间，使类与其协助函数之间的关系更明确。
[6] 将那些不修改对象值的成员函数做成const 成员函数。
[7] 将那些需要访问类的表示，但无须针对特定对象调用的成员函数做成static 成员函数。
[8] 通过构造函数建立起类的不变式。
[9] 如果构造函数申请某种资源，析构函数就应该释放一资源。
[10] 如果在一个类里有指针成员，它就要有复制操作（包括复制构造函数和复制赋值）。
[11] 如果在一个类里有引用成员，它就可能需要有复制操作（包括复制构造函数和复制赋值）。
[12] 如果一个类需要复制操作或析构函数，它多半还需要有构造函数、析构函数、复制赋值函数和复制构造函数。
[13] 在复制赋值函数里需要检查自我赋值。
[14] 在写复制构造函数时，请小心地复制每个需要复制的元素（当心默认的初始式）。
[15] 在向某个类中添加新成员函数时，一定要仔细检查，看是否存在需要更新的用户定义构造函数，以使它能够初始化新成员。
[16]
补充：软件开发 , C++ ,
