C++编程规范 101条规则、准则与最佳实践-- 读书笔记.docVIP

C++编程规范 101条规则、准则与最佳实践-- 读书笔记 C++编程规范 101条规则、准则与最佳实践-- 读书笔记 第0条 不要拘泥于小节（了解哪此东本西不应该标准化） 编程规范不应施加个人喜好或者过时的做法。 第1条 在高警告级别干净利落地进行编译 高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。 例外： 有时候，编译器可能会发出烦人的甚至虚假的警告（即纯属噪声的警告），但是又没有提供消除的方法，这时忙于修改代码解决这个警告可能是劳而无功的或者事倍功半的。如果遇到这种罕见的情形，作为团队决定，应该避免对纯粹无益的警告再做无用功：单独禁用这个警告，但是要尽可能在局部禁用，并且编写一个清晰的注释，说明为什么必须禁用。 第2条 使用自动构建系统 一次按键就解决问题：使用完全自动化（“单操作”）的构建系统，无需用户干预即可构建整个项目。 第3条 使用版本控制系统 常言道，好记性不如烂笔头：请使用版本控制系统（Version Control System,VCS）。永远不要让文件长时间登出。在新的单元测试通过之后，应该频繁的登入。确保登入的代码不会影响构建成功。 例外： 只有一个程序员且从头至尾只需一周的项目，可能不需要版本控制系统。 第4条 做代码审查 审查代码：更多的关注有助于提高质量。亮出自己的代码，阅读别人的代码。互相学习，彼此都会受益。 设计分格 第5条 一个实体应该只有一个紧凑的职责 一次只解决一个问题：只给一个实体（变量、类、函数、名字空间、模块和库）赋予一个定义良好的职责。随着实体变大，其职责范围自然也会扩大，但是职责不应该发散。 第6条 正确、简单和清晰第一 软件简单为美（Keep It Simple Software,KISS）：质量优于速度，简单优于复杂，清晰优于机巧，安全优于不安全。 第7条 编程中应知道何时和如何考虑可伸缩性 小心数据的爆炸性增长：不要进行不成熟的优化，但是要密切关注渐近复杂性。处理用户数据的算法应该能够预测所处理的数据量耗费的时间，最好不差于线性关系。如果能证明优化必要而且非常重要，尤其在数据量逐渐增长的情况下，那么应该集中精力改善算法的O（N）复杂性，而不是进行小型的优化，比如节省一个多余的加法运算。 第8条 不要进行不成熟的优化 不成熟优化的诱惑非常大，而它的无效性也同样严重。优化的第一原则就是：不要优化。优化的第二原则（仅适用于专家）是：还是不要优化。再三测试，而后优化。 例外： 在编写程序库的时候，预测哪些操作最后会用于性能敏感的代码中更加困难。但即使是程序库的编写者，在实施容易令人糊涂的优化之前，也会对很大范围内的客户代码进行性能测试。 第9条 不要进行不成熟的劣化 放松自己，轻松编程：在所有其他事情特别是代码复杂性和可读性都相同的情况下，一些高效的设计模式和编程用法会从你的指尖自然流出，而且不会比悲观的替代方案更难写。这并不是不成熟的优化，而是避免不必要的劣化。 第10条 尽量减少全局和共享数据 共享会导制冲突：避免共享数据，尤其是全局数据。共享数据会增加耦合度，从而降低可维护性，通常还会降低性能。 例外： 程序范围的设施cin、cout、cerr比较特殊，其实现方式很特别。工厂类必须维护一个注册表，记录创建给定类型时要调用哪个函数，而且通常应该有一个用于整个程序的注册表（但最好是属于工厂类，而不是属于共享全局对象） 跨线程共享对象的代码应该总是将这些共享对象的所有访问序列化。 第11条 隐藏信息 不要泄密：不要公开提供抽象的实体的内部信息。 例外： 测试代码经常需要对被测试类或者模块进行白箱访问。 值的聚合（c语言的struct）只是简单地将数据绑在一起，并没有提供任何抽象，所以它不需要隐藏数据，数据本身就是接口。 第12条 懂得何时和如何进行并发性编程 如果应用程序使用了多个线程或者进程，应该知道如何尽量减少共享对象，以及如何安全地共享必须共享的对象。 第13条 确保资源为对象所拥有。使用显示的RAII和智能指针 利器在手，不要再徒手为之：C++的“资源获取即初始化”（Resource Acquisition Is Initialization，RAII）惯用法是正确处理资源的利器。RAII使编译器能提供强大且自动的保证，这在其他语言中可是需要脆弱的手工编写的惯用法才能实现的。分配原始资源的时候，应该立即将其传递给属主对象。永远不要在一条语句中分配一个以上的资源。 例外： 智能指针有可能会被过度使用。如果被指向的对象只对有限的代码（比如纯粹在类的内部，诸如一个tree类的内部节点导航指针）可见