Clean Code 代码整洁之道 总结

代码整洁

提高代码质量，为后期维护、升级奠定基础

第一章

1. 编写可读的代码

2. 关注细节

3. 变量名命名

4. 重视代码整洁

5. 学会总结,回看之前写过的代码,多写代码

   why bad code

   时间不够、思路不对、难实现

   稍后等于永不 LeBlanc

   Bjarne Stoystrup C++语言发明者
   代码逻辑直截了当
   减少依赖关系，便于维护
   依据某种分层战略完善错误处理代码
   性能调至最优

   简单代码规则 Ron Jeffries

   1. 能通过所有测试
   2. 没有重复代码
   3. 提现系统中的全部设计理念
   4. 包括尽量少的实体，比如类、方法、函数等

   总结 减少重复代码、提高表达力，提早构建简单抽象。

   修改变量名、拆分过长的函数、消除重复代码

第二章

1. 根据具体用处命名
2. 避免使用有歧义的变量名
3. 小心使用差别较小的名称
4. 明确数据类型或者说是什么用处
5. 命名尽量可读可搜索
6. 把类和函数写的尽量小
7. 用名词/名称短语来命名类
8. 方法名应该是动词/动词短语
9. 尽量用通用的一些名称来表示
10. 相同单词用于相同的目的
11. 使用计算机专业术语
12. 添加变量名所在的有意义的语境
13. 不管重构还是自己写都需要重视命名，增加代码可读性

第三章 函数

1. 函数需要短小
2. 判断函数能否在拆出一个函数来
3. 自顶向下读代码 向下规则
4. 函数名称尽量具体、有描述性
5. 函数参数尽可能少
6. 函数参数较多时，应封装成类
7. 全局变量和局部变量要区分好
8. 函数只做一件事
9. 抽离异常处理语句
10. 消除重复
11. 结构化编程 每一个代码块有一个入口和一个出口 只有一个return 循环没有continue 和break 不能有goto
12. 可以先写出整体逻辑代码，不断优化
13. 程序就像是故事

第四章 注释

1. 注释是你代码编写的失败
2. 注释很少去维护
3. 尽量少写注释
4. 源头还会代码太糟糕
5. 还是有一些必要的注释（法律信息、信息的注释、对意图的解释、出现某些特定的情况或者问题的注释）
6. TODO 以后要写的东西，现在还没实现
7. 保证注释的正确性
8. 删除没有意义的注释
9. 日志式注释应做相应的删除
10. 不要的代码直接删掉
11. 注释信息太多
12. 注释和相关代码联系紧密
13. 代码重构和注释重构

第五章 格式

1. 保持良好的代码格式，尽量使用相同的格式规则
2. 格式会影响之后代码维护者
3. 大致的结构和框架要搭好
4. 空格和空行增加代码阅读性
5. 关联紧密的代码应该相互靠近
6. 不要把关系密切的概念放在不同的文件中
7. 变量声明靠近使用位置（函数顶部）
8. 实体变量在类的顶部声明
9. 空格可以强调字符或运算符

第6章 对象和数据结构

1. 对象内部的结构要隐藏不应该暴露出去
2. 以抽象的形态表述数据
3. 过程式代码和面向对象
4. 得墨忒耳定律
   每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
   每个单元只能和它的朋友交谈：不能和陌生单元交谈；
   只和自己直接的朋友交谈。
5. 避免混杂的数据结构或对象
6. Active Record 类似flask-sqlalchemy

第7章 错误处理

1. 必要时需要写异常处理代码
2. 针对特定语句可能抛出异常的语句增加异常，结构清楚
3. 避免传递null值
4. 错误处理隔离看待，独立于主要逻辑之外，增加代码的可维护性

第8章 边界

…

第9章 单元测试

1. 编写测试代码，用于测试
2. tdd测试驱动开发，单元测试，编写生产代码之前要编写测试代码
3. 编写整洁的测试代码，按照生产代码规范来编写
4. 维护代码也是一个大工程，如果在编写测试代码是没有规范化。
5. 测试可读性，要求简洁明了
6. 用于测试而非生产环境
7. 测试代码可以对代码的限制宽松一点，测试都需要断言断言断言
8. 功能代码分解测试，越小越好
9. 测试规则
   1. 快速
   2. 独立
   3. 可重复
   4. 自足验证
   5. 及时
10. 提高测试代码的重视程度 非常重要

第10章 类

1. 类的封装，包括变量和函数的私有性
2. 创建短小的类
3. 只有一条修改的理由，只做一件事
4. 类的内部实现内聚，变量被每个类中的方法所使用（尽量）
5. 增加抽象类以满足多变量
6. 结构要清晰，关系要理顺
7. 调整代码之后还是需要做进一步的验证、测试