代码规范
读与写所花费的时间比例远超过10:1,在写新代码的时候也在阅读旧代码,因此代码规范尤其重要
命名规范
- 名副其实(名称应该清楚的告诉读者,他为什么存在,他做了什么事,应该怎么用它),也便于查找
- 避免使用不同之处较小的名称(XYZControllerForEfficientHandlingOfStrings与XYZControllerForEfficientStorageOfStrings,难以看出区别,错误)
- 避免数字系列的命名(a1, a2…),这并没有提供正确的信息
- 使用读的出来的单词命名(genymdhms:代表生成日期,里面包含了年、月、日、时、分秒;第一眼看不懂,错误)
- 变量名和类名应该是名词或名词短语,函数名应该是动词或动词短语
函数规范
- 整洁的代码只做一件事(每个函数只服务于一个功能)
-
不应包含多层嵌套,难以理解(一般就不只做了一件事了)
如何判断 函数 是否只做一件事
(1) 函数中的语句是否在同意抽象层级(看缩进)
(2) 看是否还能再拆出一个函数
个人(我)觉得应避免使用switch语句(还需查资料验证?可以用什么代替?)
原因一:switch天生就是做N件事的,违反了单一职责原则
原因二:每次只要新加入类型的时候,就得修改,违反了开放闭合原则
-
代码块要尽可能的少,简单,应在字面意思上表达其含义(可读性)
所谓的简单应满足以下要求(依重要性排列):
- 能通过所有测试;
- 没有重复的代码;
-
函数参数:理想状态是0,其次一个(把所有参数包成一个对象,不知道哈,下来在百度哈)
-
把try/catch代码块从主体中抽离出来,因为try/catch就是在做一件事了(这个与我日常开发代码有出入,待商榷,百度哈)
注释
- 及时更新注释(代码变,注释变)
- 对于函数,在开头注明 方法的功能、描述 ;对于复杂的代码块,也要加上注释;对于复杂参数也要加上说明(其他地方看来的,代码整洁之道的作者认为 注释 越少越好,能用代码说明的就不要用注释,注释会骗人)
- TODO注释(应该做,但是由于某种原因没有做的工作)——定期查看,删除不必要的TODO注释
- 全部删掉(日志式注释:修改一次就记录)
- 及时清理注释掉的代码
- 注释 要保证离描述的代码很近
格式
- 团队成员应选用一套格式规格(现在有格式化工具,不用管)
- 在每个函数、导入声明、变量声明之间都要有空白行分开(这会形成良好的视觉外观,读各部分时都互不影响)
- 紧密相关的代码应该互相靠近(包括:函数调用,执行相似操作的一组函数等)
- 若某个函数调用了另外一个,就应该把他们放在一起(满足第三点),并且调用者在被调用的前面(自上而下的阅读习惯)
- 尽量不要有空语句体