四.注释
1.若编程语言足够有表达力，就不需要注释
2.注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败
3.程序员应当负责将注释保持在可维护、有关联、精确的高度，更应该把力气用在写清楚代码上，直接保证无须编写注释
4.不准确的注释要比没注释坏得多
注释不能美化糟糕的代码
用代码来阐述
五.格式
格式的目的
1.代码格式关乎沟通，而沟通是专业开发者的头等大事
垂直格式
1.通过间隔来区分逻辑模块
横向格式
1.适当对齐，间隔
团队规则
1.一组开发者应当认同一种模式风格，每个成员都应该采用那种风格
2.好的软件系统是由一系列读起来不错的代码文件组成的，需要拥有一致和顺畅的风格
六.对象和数据结构
数据、对象的反对称性
1.过程式代码难以添加新的数据结构，因为这要修改所有相关函数；面向对象代码难以添加新函数，因为要修改所有相关类
得墨忒耳律
1.得墨忒耳律（The Law of Demeter）：模块不应了解它所操作对象的内部情形，意味着对象不应通过存取器曝露其内部结构，因为这样更像是曝露而非隐藏其内部结构
2.混合结构，一半是对象，一半是数据结构，应避免这种结构
数据传送对象
1.最为精练的数据结构，是一个只有公共变量、没有函数的类，这种被称为数据传送对象，或DTO（Data Transfer Objects）。在与数据库通信、或解析套接字传递的消息之类场景中存在。
2.JavaBean或Active Record
3.不要塞进业务规则方法，把Active Record当做数据结构。创建包含业务规则、隐藏内部数据（可能就是Active Record的实体）的独立对象。