极客视点
极客时间编辑部
极客时间编辑部
113241 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:05
登录|注册

观点:什么是好的代码?

讲述:初明明大小:4.64M时长:05:05
开发人员编写的代码,除了用于机器执行外,更多时候是给人读的,这个读代码的人可能是后来的维护人员,但更多时候是隔了一段时间后的作者本人。日前,阿里工程师马飞翔在公众号淘宝技术(ID:AlibabaMTT)中盘点了好代码所具备的各个特点,以下为重点内容。
首先,好的代码一定是整洁的,整洁的代码一定是高内聚低耦合的,也一定是可读性强、易维护的。

高内聚低耦合

高内聚低耦合几乎是每个程序员都会挂在嘴边的,但这个词太过于宽泛,太过于正确,所以聪明的编程人员们提出了若干面向对象的设计原则来衡量代码的优劣,如下:
开闭原则 OCP (The Open-Close Principle)
单一职责原则 SRP (Single Responsibility Principle)
依赖倒置原则 DIP (Dependence Inversion Principle)
最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
里氏替换原则 LSP (Liskov Substitution Principle)
接口隔离原则 ISP (Interface Segregation Principle)
组合 / 聚合复用原则 CARP (Composite/Aggregate Reuse Principle)

可读性

代码只要具有了高内聚和低耦合就足够好了吗?并不见得,代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该具有强可读性。可以从以下几个方面考虑整洁代码,提高可读性。

1. 命名

大到项目名、包名、类名,小到方法名、变量名、参数名,甚至是一个临时变量的名称,其命名都是很严肃的事,好的名字需要斟酌。可以从以下四点来区别代码命名的优劣:
名副其实,不需要注释解释即可明白其含义。
容易区分,开发者很容易就会写下非常相近的方法名,仅从名称无法区分二者,这样在调用时也很难抉择要用哪个,需要去看实现的代码才能确定。
可读、易读,命名最好不要用自创的缩写,或者中英文混写。
命名足够短,在足够表达其含义的情况下越短越好。

2. 格式

良好的代码格式也是提高可读性非常重要的一环,分为垂直格式和水平格式。
垂直格式通常一行只写一个表达式或者子句。一组代码代表一个完整的思路,不同组的代码中间用空行间隔,如果去掉了空行,可读性会大大降低,而水平格式要有适当的缩进和空格。另外,同一个团队的风格尽量保持一致。

3. 类与函数

类和函数应该短小,更短小,过长的函数可读性一定差,往往也包含了大量重复的代码。
同一个函数的每条执行语句应该是统一层次的抽象。比如写一个函数需要给某个 DTO 赋值,然后再调用接口,接着返回结果。那么这个函数应该包含三步:DTO 赋值,调用接口,处理结果。如果函数中还包含了 DTO 赋值的具体操作,那么说明此函数的执行语句并不是在同一层次的抽象。
此外,参数越多的函数,调用时越麻烦,尽量保持参数数量足够少,最好是没有。

4. 注释

注释不能美化糟糕的代码。当企图使用注释前,先考虑是否可以通过调整结构、命名等操作,消除写注释的必要。
好的注释提供信息、表达意图、阐释、警告。可能你也经常遇到这样的情况:注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了,而注释并没有跟进变化,所以,注释最好提供一些代码没有的额外信息,展示自己的设计意图,而不是写具体如何实现。
删除掉注释的代码也有必要,Git 等版本控制已经记录了代码的变更历史,没必要继续留着过时的代码,注释的代码也会对阅读等造成干扰。

5. 错误处理

在这个方面需要注意四点,其一,错误处理很重要,但他不能搞乱代码逻辑。错误处理应该集中在同一层处理,并且错误处理的函数最好不包含其他的业务逻辑代码,只需要处理错误信息即可。
其二,抛出异常时提供足够多的环境和说明,方便排查问题。异常抛出时最好将执行的类名,关键数据,环境信息等均抛出,此时自定义的异常类就派上用场了,通过统一的一层处理异常,可以方便快速地定位到问题。
其三,特例模型可消除异常控制或者 null 判断。大多数的异常都是来源于 NPE,有时候这个可以通过 Null Object 来消除掉。
其四,尽量不要返回 null ,不要传 null 参数,这也是为了尽量降低 NPE 的可能性。
以上就是今天的内容,希望对你有所帮助。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • dqs
    感谢您的文章
    2
  • 杨先生
    可以作为 code review的标准啦
收起评论
大纲
固定大纲
高内聚低耦合
可读性
1. 命名
2. 格式
3. 类与函数
4. 注释
5. 错误处理
显示
设置
留言
2
收藏
99
沉浸
阅读
分享
手机端
快捷键
回顶部