《代码整洁之道》读后总结

一、命名规范

匈牙利命名法：变量名=属性+类型+对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。

驼峰法：混合使用大小写字母来构成变量和函数的名字，如同驼峰一般起伏。

#### 样例 ####
# g_:全局变量
# m_:类成员变量
# s_:静态变量
# c_:常量
g_AccountMgr = None  # 全局账号管理单例
m_sAccount = ""  # 类中的账号变量

# b: bool
# i: int
# f: float/double
# lst: list
# 等等类型
lstLoginAccount = []  # 登录中账号列表
bLoginSuccess = True  # 是否登录成功

# 驼峰法。意会即可，根据自己喜好编写
PrintEmployeePaychecks();
printEmployeePaychecks();
print_employee_paychecks();

少用常量，多用赋值变量，目的是更易于查找和修改。

比如用网页请求的返回值，用变量表示之后，比起单纯的404更容易理解，而且哪些地方有这个判断，全局搜索很容易搜到，还有就是如果错误码需要修改，只需要把这个变量修改，就可以覆盖所有调用的地方了。

这种推荐在一个常量（字符串或数字都可以）有多数地方用到再用，不然会增加代码的复杂度。（一切问题都来自于系统的复杂度。 ——《人月神话》）

NOT_FOUNT_CODE = 404

 

二、函数

1）得墨忒耳定律：模块不应该了解它所操作对象的内部情况。

2）函数应该做一件事。做好一件事。只做一件事。 目的是在1条件下，调用这个代码的人理解和函数实现就会有差异，理解上的差异就是系统的bug。

3）当参数出现三个或以上的时候，考虑用数据结构。

#  基础数据结构
def Login(dData):
    sAccount, sPwd, sName, iAge = dData
# 类
class LoginData():
    m_sAccount = ""
    m_sPwd = ""
    m_sName = ""
    m_iAge = -1
def Login(oLoginData):
    pass

 

三、注释

　　不要在工作代码注释中用签名，因为离职之后会导致这段注释的错误。不要因为个人成就感，导致代码的逐步腐烂。

 

四、格式

　　C++的“剪刀原则”：所有实体变量放在类的底部。

　　Java中，惯例是放在顶部。个人写代码倾向顶部。

 

五、对象与数据结构

　　过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。

　　面向对象代码便于在不改动既有函数的前提下添加新类。

　　反过来说，过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。

　　不要机械化的编写代码，oop并非完美，从需求出发进行设计。

 

六、错误处理

　　别返回null值。

　　null值导致了函数返回不同类型的数据，使用者需要小心翼翼的调用这个函数。这会导致函数中有各种判断null的逻辑，而且如果去掉了，很容易报错！

 

七、单元测试

1）需要测试用例

　　测试用例可以复用，为所有维护这个模块的人使用，所以需要写测试用例，这是一劳永逸的事。

　　测试用例需要跟随模块的维护而维护，因此需要遵守代码规范，而且可读性要高，然后会给后续接手的人增加额外的理解成本。

2）编写模式

　　测试用例的编写模式：构造 —— 操作 —— 检验 （build - operate - check，简称BOC模式）

　　每个测试用例都应该有且仅有一个断言语句。目的是可以快速定位问题，方便理解这个用例是干什么的。　　

3）F.I.R.S.T规则

　　快速（Fast）测试足够快。测试应该能快速运行。测试运行缓慢，你就不会想要频繁地运行它。如果你不频繁运行测试，就不能尽早发现问题，，也无法轻易修正，从而也不能轻而易举的清理代码。最终，代码就会腐坏。

　　独立（Independent）测试应该项目独立。某个测试不应为下一个测试设定条件。你应该可以单独运行每个测试，以及以任何顺序运行测试。当测试互相依赖时，头一个没通过就会导致一连串的测试失败，使问题诊断变得困难，隐藏了下级错误。

　　可重复（Repeatable）测试应当可在任何环境中重复通过。你应该能够在生产环境、质检环境中运行测试，也能够在无网络的列车上用笔记本电脑运行测试。如果测试不能在任意环境中重复，你就总会有个解释其失败的接口。当环境不具备时，你也会无法运行测试。

　　自足验证（Self-Validating）测试应该有bool值输出。无论是通过或失败，你不应该查看日志文件来确认测试是否通过。你不应该手工对比两个不同文本文件来确认测试是否通过。如果测试不能自足验证，对失败的判断就会变得依赖主观，而运行测试也需要更长的手工操作时间。

　　及时（Timely）测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试，你会发现生产代码难以测试。你可能会认为某些生产代码本身难以测试。你可能不会去设计可测试的代码。

 

八、并发模型

　　生产者-消费者模型：生产的工作放入到队列中，消费者也从队列中获取工作。

　　读者-作者模型：三种关系（读者与读者之间无关系，写者与写者之间互斥，读者与写者之间互斥），两个角色（读者、写者），一个场所。

　　宴席哲学家（哲学家模型）：单人享用，循环互斥。

 

九、死锁

　　四个条件：互斥；上锁及等待；无抢先机制；循环等待。

 

十、代码草稿

　　代码整洁，是一门艺术，不是一开始就能编写出整洁的代码的，需要长年累月的修正，才能得到整洁的代码。

　　就像小学老师会努力让我们写作文草稿一样，这是一个逐步改进的过程。