This repository was archived by the owner on Jan 6, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
This repository was archived by the owner on Jan 6, 2023. It is now read-only.
clean code 学习笔记 #1
Open
Description
如何提高代码可读性
如何让代码更好的表达出来,此时凸显英语的重要性!!!
命名
-
命名需要表述清晰,不能使用
I l O 1 0等容易混淆的字母进行命名 -
命名需要表述准确,尽可能达到
顾名思义的效果
注释
当代码较为复杂,可以使用注释表述其意。好的命名可以达到顾名思义的效果,不值得写注释
书中推荐使用注释的几种场景:
-
对意图的解释。 可以解释某一部分代码用来干什么
-
阐述晦涩难明的参数或者返回值意义 。
一般是标准库的数据类型,无法修改。如果是自定义的数据类型,建议修改命名便于理解
-
警示其他人。 例如 修改某一行会出bug 等等警示信息
-
// Todo
参数
- 函数参数尽量不要太多
- 标识参数不要用布尔值。(这样还需要联系上下文理解参数意义与不同场景)
代码格式
-
1、实体变量统一置顶
-
2、自上而下的展示函数调用依赖顺序
- 具体规则:被调用的函数应该放在执行调用的函数下面。
- 表现形式:像报纸文章一样,概念先出来,然后表述大体流程,最后详细体现底层细节。
- 优点 : 快速阅读代码文件,从前几个函数即可知要旨,不必成溺到细节
如何提高代码可用性
对象和数据结构
-
使用抽象 : 减少代码影响
-
具体:例如多态,调用方不需要关注具体的实现细节,只需了解该调用什么方法达到效果。
-
推荐:设计模式 **里氏替换原则 **
里氏替换原则: 通过抽象建立规范,具体实现在运行时在替换抽象
-
优点:需求会变,代码也会变,可以隔离修改代码带来的影响
-
-
使用封装和继承 :代码复用
错误处理
- 程序出现逻辑错误,例如参数校验等。 一般需要通过错误码来返回。
- 程序无法处理的错误,例如网络连接故障,文件权限等。 一般通过 panic 抛出,并捕捉其错误
单元测试
测试的目的之一就是通过实例起到文档的作用
常用模式: 构造 - 操作 - 检验 (Build - Operate - Check)
目前个人用到两种测试方法:
-
代码覆盖测试 : 测试用例尽可能覆盖每一行代码,保障代码能运行
-
代码场景测试 : 测试用例尽可能覆盖不同场景,保障场景都能覆盖
代码的优化
引用传递
尽量使用指针或者引用传递,减少开销。
并发
并发是一种解耦策略,将 做什么(目的) 和 何时做 (时机)分解开
Activity
Metadata
Metadata
Assignees
Labels
No labels