By Herb Sutter, Andrei Alexandrescu 著
树人 译组织和方针问题
0. 不要为小事斤斤计较。（或者说是：知道什么东西不需要标准化）
少说废话，捡有必要的说：不要把个人的品味或废弃的实践强加于他人。
1. 在高警告级别下干净地编译代码。
要把警告放在心上：使用你的编译器的最高警告级别。要求干净（没有警告）的构建。理解所有的警告。通过修改你的代码来消除警告，而不是降低警告级别。
2. 使用自动构建系统。
触动单一的按钮：使用一个不需人工干预的构建整个工程的完全自动化（“单动作”）的构建系统。
3. 使用版本控制系统。
好记性不如烂笔头：使用版本控制系统（VCS）。永远不要让文件长时间地签出（check out）。在你通过更新的单元测试后，要经常性地签入（check in）。使得签入的代码不会破坏构建。
4. 投资于代码评审。
评审代码：人多力量大。向他人展示你的代码，阅读其他人的代码。大家都将受益。
设计风格
5. 一个实体一个内聚的责任。
一个时刻关注一件事情：赋予每个实体（变量，类，函数，名字空间，模块，库）一个定义明确的责任。随着实体的演化，其责任的作用域也随之加大，但其责任不能发散。
6. 正确性，简单性和清晰性是第一位的。
KISS（保持软件简单）：正确优于快速。简单优于复杂。清晰优于伶俐。安全优于不安全。（参见Item83和Item99）
7. 知道什么时候和如何为可伸缩性编码。
小心爆炸性的数据增长：不要过早地优化，着眼于渐进的复杂度。
对于作用于用户数据的算法，数据处理的复杂度应该是可预测的，最好是不比线性差。在证明了优化是有必要而且重要以后（特别是由数据量增加所引起的），应该集中于提高big-Oh复杂度，而不是作像少用一个额外的加法那样的优化。
8. 不要过早地优化。
无故加鞭（拉丁谚语Spur not a willing horse）：过早地优化是没有结果的,就像它很令人着迷一样。
优化的第一个原则是：不要去动它。优化的第二个原则（只对专家来说）是：还是不要去动它。衡量两次，优化一次。
9. 不要过早地悲观。
自己要轻松点，代码也是一样：在其他所有的情况都相同的情况下（尤其是代码复杂性和可读性），使用某个有效的设计模式和编码惯用法应该是你信手拈来的事，而且它不能比悲观的候选方法更难于编写。这并不是过早的优化；它是在避免没有必要的悲观。
10. 使全局和共享数据最少。
共享会引起争夺：避免共享数据，尤其是全局数据。共享数据会增加耦合性，它降低了可维护性，而且常常会降低效率。
11. 隐藏信息。
不要泄密：不要暴露一个提供了抽象的实体的内部信息。
12. 知道什么时候和如何为并行编码。
线程安全：如果你的应用程序使用了多线程或多进程，你就应该尽可能地减少共享对象（参见Item10），而且要安全地共享这些对象。
13. 保证资源被对象所拥有。使用显式的的RAII和智能指针。
当你有动力工具时，不要手工去锯：C++的“资源获取既是初始化”（RAII）惯用法是一个强大的正确的资源处理工具。RAII允许编译器提供强大而且自动化的保证，而在别的语言中这些保证需要脆弱的手工编写的惯用法来提供。在申请一块原始资源时，随即把它传递给一个固有的对象。绝不要在单一一个语句中申请多个资源。
