这一章讲的是结对编程,结对编程的好处很多,有助于提升代码质量,让两个人都对代码负责,防止甩锅扯皮。但是现实是基本没有公司会这么干,毕竟对于很多中小型的公司来说,人力成本还是很高的。书中的一些编码规范倒是值得学习的,包括代码风格与设计规范。
代码规范
代码风格规范
- 1.缩进问题
这个问题因人而异,我个人还是喜欢用tab键的,而且喜欢使用IDE的快捷键进行代码格式化。 - 2.命名
- 在变量名中不要提到类型或其他语法方面的描述。如表示全年假日的变量,不要用arraylistOfholidays,应该直接用holidays
- 避免过多的描述,这样会使变量名很长,不方便阅读
- 如果信息可以从上下文中得到,那么类信息就不必写在变量名中。如在Teacher表中,变量不要写teacherName,应该直接写name
- 大小写:类/函数名用Pascal,变量用Camel
- 3.注释
- 注释是为了解释程序做了什么,为什么这么做,以及要特别注意的地方
- 复杂的注释应该放在函数头
- 注释也要随着程序的修改而不断更新,毕竟一个误导的注释比没有注释更糟糕
程序员讨厌写注释,更讨厌别人不写注释。我自己的注释写的很随意,恐怕只有自己能看懂,这方面要改正。
代码设计规范
- 函数:只做一件事,并且要做好。
好像单一职责原则 - 构造函数
- 不要在构造函数中做复杂的操作,简单初始化所以数据成员即可
- 构造函数不应该返回错误
- 运算符的实现必须非常有效率,如果有复杂的操作,应定义一个单独的函数
深以为然,自己就在判断语句里写过复杂的逻辑,导致维护比较麻烦 - 不要用异常作为逻辑控制来处理程序的主要流程
代码审查
代码审查的目的
- 找出代码的错误
- 发现逻辑错误
- 发现算法错误
- 发现可能需要改进的地方
我所在的团队也做过代码评审,但更多形式大于意义,坐在下面的同事更关心业务,而很少在代码层面上提出意见。所以在轮完一遍之后,便没有后续了。
我是希望看到好的代码的,也是乐于去学习的,比如他们用了好的设计模式或者算法,我就想去抄。
而且阅读优秀的代码也是一种享受,也会激励我更好的编程。毕竟知行要合一,好的编码规范要在做中学。
但我也很怕把自己的屎山代码拉出来给众人看,这种感觉真的不舒服,但也会鞭策我,让我学习和模仿优秀的代码。
做标记
- todo
- review
- bug
我只用过todo,而且是滥用,定期review应该可以将标记清除,毕竟一个一年前的todo,现在也没人敢动,不知道到底有没有实现。
清除无用的代码
很多人想保留尽可能多的代码,因为以后可能会用上,这样导致程序文件里有很多注释掉的代码,这些代码都可以删除,因为源代码控制已经保存了原来的老代码。
这个感触挺深的,注释掉的代码看着很不爽,还有废弃注解之类的东西,感觉没用了干掉就完事了,无用的代码反而误导,明天就去把项目上用不到的代码清除掉。