第0条不要拘泥于小节.docVIP

第0条　不要拘泥于小节（又名：了解哪些东西不应该标准化） ? ? 无需在多个项目或者整个公司范围内强制实施一致的编码格式。 ? 第1条　在高警告级别干净利落地进行编译 ? ? 高度重视警告：使用编译器的最高警告级别。通过修改代码而不是降低警告级别来排除警告。 ? 第2条　使用自动构建系统 ? ? 一键构建。 ? 第3条　使用版本控制系统 ? ? svn。 ? 第4条　在代码审查上投入 ? ? 做好同行评审。 ? 设计风格 第5条　一个实体应该只有一个紧凑的职责 ?? ?一次只解决一个问题。一个实体或一个模块，只赋予一个良好的职责，不要乱发散。 ? 第6条　正确、简单和清晰第一 ??? 代码是写给人看的，要简单、清晰、可靠。 ? 第7条　编程中应知道何时和如何考虑可伸缩性 ?? ?关注算法的优化，注意复杂性。 ? 第8条　不要进行不成熟的不要进行不成熟的优化，优化应该使代码更清晰易读，易理解，易重构，而不要为了所谓的性能，让代码变得更复杂和更差的可读性。 ? 第9条　不要进行不成熟的劣化 ?? ?不要使用低效的用法，比如++，应倾向于使用前++，而不是会产生临时变量的后++。 ? 第10条　尽量减少全局和共享数据 ??? 全局和共享数据，会增加耦合度，降低可维护性。 ? 第11条　隐藏信息 ??? 模块或对象设计，内部实现与外部接口要分离，减少依赖性。 ? 第12条　懂得何时和如何进行并发性编程 ?? ?多线程，与平台相关。小心使用各种多线程技术。 ? 第13条　确保资源为对象所拥有。使用显式的RAII和智能指针 ??? “资源获取即初始化”，是处理资源获取和释放的C++惯用法。局部对象的构造函数和析构函数，竟然可以解决资源自动释放的难题，C++真是无时无刻不让人惊叹。 ? 编程风格 第14条　宁要编译时和连接时错误，也不要运行时错误 ? ? C++属于静态类型语言，应当好好利用其静态类型检查。多依赖编译时检查，而不要过多的依赖运行时检查。 第15条　积极使用const ? ? Const是我们的好朋友。 ? 第16条　避免使用宏 ? ? C++中几乎不需要宏：const/enum，inline，template，namespace等多种机制，分别取代宏大作用。当然头文件中的#ifndef那个还是没有好的选择。 第17条　避免使用“魔数” ? ? 硬编码的数字，应当使用常量代替。 ? 第18条　尽可能局部地声明变量 ? ? 变量用的着的时候才定义，定义马上初始化。 ? 第19条　总是初始化变量 第20条　避免函数过长，避免嵌套过深 第21条　避免跨编译单元的初始化依赖 ? ? 不同编译单元中的名字空间级对象，其初始化顺序是未定义的。 ? 第22条　尽量减少定义性依赖。避免循环依赖 ? ? 只需要声明的时候，就不要提供定义。 ? 第23条　头文件应该自给自足 ? ? ?应该确保每个头文件都能够独立进行编译，需要包含其内容所依赖的所有头文件。 ? 第24条　总是编写内部#include保护符，决不要编写外部#include保护符 ? ? #ifndef xxx #define xxx #endif，这个破玩意。 ? 函数与操作符第25条　正确地选择通过值、（智能）指针或者引用传递参数 分清输入/输出参数。 ? 第26条　保持重载操作符的自然语义 ??? 不要定义和操作符名称不符的重载。 ? 第27条　优先使用算术操作符和赋值操作符的标准形式 ? 第28条　优先使用++和--的标准形式。优先调用前缀形式 ? ? T T::operator++(); //前缀形式 ? ? T T::operator++(int); //后缀形式 ? 第29条　考虑重载以避免隐含类型转换 ? 第30条　避免重载、||或 ,（逗号） ? 第31条　不要编写依赖于函数参数求值顺序的代码 ??? 不同的编译器处理函数参数求值顺序可能不一样。 ? 类的设计与继承第32条　弄清所要编写的是哪种类 ? ? 不同种类的类适用于不同用途。值类？基类？traits类？策略类？异常类？ ? 第33条　用小类代替巨类 ? ? 小类更易于编写，更易于保证正确、测试和使用。小类更有可能适用于各种不同情况。 ? ? 小的类粒度层次恰到好处，被人使用和重用的可能性也越大，更易于部署。 ? 第34条　用组合代替继承 ? ? 继承是紧密的耦合关系。“组合”就是指在一个类型中嵌入另一个类型的成员变量。用这种方式能够保存和使用对象，还能控制耦合强度。 ? 第35条　避免从并非要设计成基类的类中继承 ? ? 不要再不需要的情况下使用继承。要继承的话，就要设计专门的基类。 ? 第36条　优先提供抽象接口 ??? 抽象接口是完全由（纯）虚函数构成的抽象类，没有状态（成员数据）。抽象基类