manager推荐（给另一个实习生）的书，翻了一下感觉还挺好的，这本书的目的就是让你写出后面的代码维护者看了以后不会想打你的代码。
特别是里面每章结尾的checklist挺不错的，手打了一些感觉有点笨B，更新与否看缘分了。
Chapter 10
CHECKLIST: General Considerations In Using Data
初始化变量
- 每一个子程序都检查其输入参数的正确性吗？
- 变量声明位置靠近变量第一次使用的位置吗？
- 尽可能在声明变量的同时初始化变量吗？
- 如果无法同时声明和初始化变量，是否在靠近第一次使用变量的位置声明变量？
- 计数器和累加其是否经过适当的初始化？如果需要再一次使用，是否重新初始化？
- 代码在通过编译器编译的时候是不是没有警告信息？
- 如果你使用的语言允许隐式声明，你为由此可能引发的问题做好补偿措施了吗？
使用数据的其他事项
- 如果可能，所有变量都被定义为具有最小的作用域吗？
- 各变量的引用点都尽可能集中在一起吗？对同一变量的两次相邻引用，或者变量的整个生命期都这样做了吗？
- 控制结构符合数据类型吗？
- 所有声明的变量都用到了吗？
- 变量都在合适的事件绑定了吗？——也就是说，你有意识地在晚期绑定所带来的灵活性和增加的复杂度之间作出平衡了没？
- 每个变量都有且仅有一种用途吗？
- 每个变量的含义都很明确并且没有隐含含义吗？
Key Points
- 最小化每个变量的作用域，把同一变量的引用点集中在一起。把变量限制在子程序或类的范围内。避免使用全局数据。
- 把使用相同变量的语句尽可能集中在一起。
- 早期绑定会减低灵活性，但有助于减小复杂度。晚期绑定可以增加灵活性，同时增加复杂度。
- 把每个变量用于唯一的用途。
Chapter 11
CHECKLIST: Naming Variables
命名的一般注意事项
- 名字完整并准且表达了变量所代表的含义吗？
- 名字反映了现实世界的问题而不是编程语言方案吗？
- 名字足够长，可以让你无需苦苦思索吗？
- 如果又计算值限定符，它被放在名字最后吗？
- 名字中使用Count或者Index来替代Num了吗？
为特定类型的数据命名
- 循环下表的名字有意义吗？（如果循环长度超过一两行代码或者出现了嵌套循环，那么就应该是ijk以外的名字
- 所有的临时变量都重新命名为更有意义的名字了吗？
- 当布尔变量的值为真，变量名能准确表达含义吗？
- 枚举类型的名字中含有能表示其类别的前缀或者后缀了吗？
- 具名常量命名是否根据它们所代表的抽象实体而不是它们引用的数字？
命名规则
- 规则能够区分局部数据、类数据和全局数据吗？
- 规则能够区分类型名、具名常量、枚举类型和变量名吗？
- 规则能够在编译器不强制检测只读参数的语言里标识出子程序中的输入参数吗？
- 规则尽可能与语言的标准规则兼容吗？
- 名字为了可读性加以格式化吗？
短名字
- 代码使用了长名字吗？（除非有必要使用短名字）
- 是否避免只为了省一个字符而缩写名字的情况？
- 所有单词的缩写方式都一致吗？
- 名字能够读出来吗？
- 避免使用容易被看错或者读错的名字吗？
- 在缩写对照表中对短名字作出说明吗？
常见命名问题：你避免使用……
- ……容易让人误解的名字吗？
- ……有相近含义的名字吗？
- ……只有一两个字符不同的名字吗？
- ……发音相近的名字吗？
- ……包含数字的名字吗？
- ……为了缩短而故意拼错的名字吗？
- ……英语中经常拼错的名字吗？
- ……与标准库子程序名或者预定义变量名冲突的名字吗？
- ……过于随意的名字吗？
- ……含有难读字符的名字吗？
Key Points
- 好的变量名是提高程序可读性的一项关键要素。对特殊种类的变量，比如循环下标和状态变量，需要加以特殊的考虑。
- 名字要尽可能的具体。太模糊、太通用的名字通常是不好的。
- 命名应该能够区分局部数据、类数据和全局数据。它们还应该可以区分类型名、具名常量、枚举类型和变量名。
- 无论做哪种类型项目，都应该采用某种命名规则。所采用的规则的种类取决于程序规模，以及项目人数。
- 现代编程语言很少需要用到缩写。如果真的要使用缩写，请使用项目缩写词典或者标准前缀来帮助理解缩写。
- 代码阅读的次数远远多余编写次数。确保取的名字侧重于阅读方便而不是编写方便。