背景
代码本就该是直接简单的,横就是横,纵就是纵,架构原本也本是清晰明了的,模块是模块,过程是过程。
可随着项目生命周期的变长,随着需求不断的被实现,面对不同思想的人,不同场景的要求,不同技能水平的实施,就让原本平直的路走成了立交桥,织成了逻辑网。这时候再浏览代码,要走通某一个流程,即便是熟悉路况的“本地人”,编写代码的“原住民”也不一定能走的顺畅。
Robert Martin的这句话非常合适:
“唯一能有效测量代码质量的方式是每分钟说多少个What-the-Fk ”
让我深入解释一下:
做代码回顾的时候,我的脑海会涌现出三种不同的情绪:
· What-the-Fk (厌恶)—这代码并不需要.**
· What-the-Fk (欣赏)— 小伙子很机智**
· What-the-Fk (无奈)—不知道在说什么**
所以当我们看代码的时候,是什么最先影响我们呢?是代码的整洁漂亮。同时书写整洁漂亮的代码是一名伟大的软件匠人的标志。
命名
Kendrick Lamar很好的解释道:
”如果我要讲一个真实的故事,我会从我的命名开始“
我们命名函数、类、参数、包以及其他。
你的命名应该望文知义。选择好的名称会花时间,但是当其更艰难复杂的时候却可以节省更多时间。所以注意你的命名,如若有合适的名字就替换掉。每个阅读你代码的人都会因此而很感谢你。
牢记变量、函数或者类的名称应该要回答这三个大问题:存在的理由?做了什么?和如何使用?
函数只做一件事
这里有两条书写整洁函数的黄金定律:
· 代码应该少
· 函数应该专注做一件事,并且做精
所以这也意味着你的函数不应该太大来嵌套其他结构。同时,函数的缩进,不应该大于一个或者两个。该技巧可以使得代码更容易阅读理解消化。除此之外,我们也要使得函数内的语句处于同一个抽象程度。
注释并不能弥补劣质的代码
Venus Williams曾很好地说道:
“每个人有自己的注释,这就是谣言开始的方式”
注释就像两面刀。没有什么比得上放置妥当的注解。另一方面,没有比无聊无用的注解更浪费空间的。同时没有比传递错误信息的注解更具有破坏力的。
简而言之,注释至多是个必要的恶魔。为什么这么说?虽然不是一直但是大部分时候,注释越老,维护起来越困难,大部分程序员都因为不维护注释而臭名昭著。
代码移动和更改:代码块移动到其他地方,而注释不随着移动,就会成为一个问题!
要牢记,带有一点注释并且整洁和有表现力的代码,要远远好过复杂并带有大量注释的代码。不要浪费时间去解释你写的代码,而去投入时间去使其整洁。
重构清晰代码的技能习惯
没有人一开始就能写出优美散文一样的代码,整洁的代码是用心重构出来的。
不清晰的代码总是会触犯标准,对临床医学来讲病人生什么病,开什么处方,吃什么药是有章可循的。坏代码违反整洁标准的哪一条,就使用哪一条的处方来修改。这个修改的处方和药是可以积累和总结的,而且有已经总结好的经验。剩下的是学习和养成习惯。
对已有代码的整洁化不是大范围的重写,是在保证不影响已有功能的前提下坚持做的改进优化。
唯有源头活水来,甲严格执行整洁之道的准则,乙坚持己见,丙随意而为,即使甲有熟练的整洁技能和习惯也改不完项目的所有问题。
对编程来讲,一个人的习惯是能力,一个团队的能力才是习惯。
《本文》有 0 条评论