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