第4条：在代码审查上投入
审查代码：更多的专注有助于提高质量 。亮出自己的代码，阅读别人的代码。互相学习，彼此都会受益。
---------------------------------------------------------------
设计风格
第5条：一个实体应该只有一个紧凑的职责
一次只解决一个问题：只给一个实体（变量、类、函数、名称空间、模块和库）赋予一个定义良好的职责。随着实体变大，其职责范围自然也会扩大，但是职责不应该发散。这个类似于面向对象的单一模块单一职责原则。
第6条：正确、简单和清晰第一
- 软件简单为美：正确优于速度。简单优于复杂。清晰优于机巧。安全优于不安全。
- 要避免使用程序设计语言中的冷僻特性。应该使用最简单的有效技术。
- 应该使用命名变量，而不要使用临时变量，作为构造函数的参数
- 是一个正确的程序变快，比使一个快速的程序正确要容易的多。
第7条：编程中应该知道何时和如何考虑可伸缩性
- 不要进行不成熟的优化，但是要密切关注渐进复杂性。
- 一个算法如果具有恶性（差于线性）的渐近行为 ，那么再强大的系统也迟早会被更多的数据所威胁。
- 使用 不够清晰的算法，为永远都不会成为现实的大数据量做好准备，这样的不成熟的优化显然是错误的。
- 即使不知道数据量是否会达到成为某个特定计算的问题，默认情况下也应该避免使用不能很好地应付用户数据量（可能增加）的算法，除非这种伸缩性不好的算法有明显的清晰性和可读性方面的好处。（见第6条)
- 使用灵活的、动态分配的数据，不要使用固定大小的数组
- 了解算法的实际复杂性
- 优先使用线性算法或者尽可能快的算法
- 尽可能避免劣于线性复杂性的算法
- 永远不要使用指数复杂性的算法。
- 尽可能优先使用线性算法
第8条：不要进行不成熟的优化
不成熟优化的诱惑非常大，而他的无效性也同样严重。优化的第一原则就是：不要优化，第二原则是：还是不要优化。再三测试，而后优化。
以性能为名，使设计或者代码更加复杂，从而导致可读性变差，本质上对程序没有真正的好处。
让一个正确的程序更快速，比让一个快速的程序正确，要容易的太多太多。
不要把注意力集中在如何使代码更快上；首先关注的应该是使代码尽可能的清晰和一度。清晰地代码更容易正确编写，容易理解，容易重构，容易优化。
第9条：不要进行不成熟的劣化
高效的设计模式和编程习惯可以避免不必要的劣化。
不成熟的劣化指编写一些没有必要的，可能比较低效的程序：
- 在使用可以通过引用传递的时候，却定义了通过值传递的参数
- 在使用前缀++操作符很适合的场合，却使用后缀版本。
- 在构造函数中使用赋值操作而不是初始化列表
构造清晰又有效地程序有2中重要的方式：使用抽象（item11，36）和库（item 84）
第10条：尽量减少全局和共享数据
共享会导致冲突：避免共享数据，尤其是全局数据。共享数据会增加耦合度，从而降低可维护性，通常还会降低性能。
避免使用名字空间作用域中具有外部链接的数据或者作为静态类成员的数据。这些数据会使程序逻辑变法咋，是程序的不同部分耦合的更加紧密。还会对单元测试产生不良影响。
如果必须使用全局的、名字空间作用域的或者 静态的类对象，一定要仔细的对其进行初始化。
应该尽量降低类之间的耦合，尽量减少交互。
名字空间作用域中的对象、静态成员对象或跨线程共享的对象会减少多线程和多处理器环境中的并行性，往往是产生性能和可伸缩性瓶颈的原因。
第11条：隐藏信息
不要公开提供抽象的实体的内部信息
为了尽量减少操作抽象的调用代码和抽象的实现之间的依赖性，必须隐藏实现内部的数据。
信息隐藏主要从2个方面降低了项目的成本，1：它限制了变化的影响范围。2：他强化了不变式。
绝对不要将类的数据成员设为public（item41），或者公开指向他们的指针或句柄而使其公开（item42）