前言
代码本就该是直接简单的，横就是横，纵就是纵，架构原本也本是清晰明了的，模块是模块，过程是过程。
可随着项目生命周期的变长，随着需求不断的被实现，面对不同思想的人，不同场景的要求，不同技能水平的实施，就让原本平直的路走成了立交桥，织成了逻辑网。这时候再浏览代码，要走通某一个流程，即便是熟悉路况的“本地人”，编写代码的“原住民”也不一定能走的顺畅。
Robert Martin的这句话非常合适：
“唯一能有效测量代码质量的方式是每分钟说多少个What-the-Fk ”
让我深入解释一下：
做代码回顾的时候，我的脑海会涌现出三种不同的情绪：
· What-the-Fk (厌恶)—这代码并不需要.**
· What-the-Fk (欣赏)— 小伙子很机智**
· What-the-Fk (无奈)—不知道在说什么**
所以当我们看代码的时候，是什么最先影响我们呢？
是代码的整洁漂亮。
同时书写整洁漂亮的代码是一名伟大的软件匠人的标志。
这里有两个涉及到学习这门卓越技术的要点- 知识与练习。知识可以教会职业中所需的模式、原则、实践和启发式。但是只有通过不断的练习和努力工作，这些知识需要被才能成为你的一部分。
所以简而言之，学习书写整洁的代码是艰难的。你必会为此付出汗水。你必将会在实践、跌跌撞撞、失败和熟练中一遍一遍循环直到掌握。这里没有简单的方法或窍门。
这里有一些你可以掌握的编写整洁美丽代码的方法。
“名称说明什么”
Kendrick Lamar很好的解释道：
”如果我要讲一个真实的故事，我会从我的命名开始“
在软件中名称到处都是。我们命名函数、类、参数、包以及其他。我们命名源文件和目录以及里面的一切。我们不断的命名，从而使其成为整洁代码引擎中最重要的部分。
你的命名应该望文知义。选择好的名称会花时间，但是当其更艰难复杂的时候却可以节省更多时间。所以注意你的命名，如若有合适的名字就替换掉。每个阅读你代码的人都会因此而很感谢你。
牢记变量、函数或者类的名称应该要回答这三个大问题：存在的理由？做了什么？和如何使用？
这不仅需要好的描述技巧，同时也需要跨越边界的共同文化背景，没有人能比你自己更好地教导你
“函数应该只做一件事.”
Louis Sullivan曾漂亮地说道.
“功能决定设计”
每个系统都是由程序员设计，从一个特定领域的语言搭建起来的。函数是语言的动词，而类是名词。在任何编程语言中，函数通常是系统中的第一行，编写好的函数是写好代码的实质所在。
这里有两条书写整洁函数的黄金定律：
· 代码应该少
· 函数应该专注做一件事，并且做精
所以这也意味着你的函数不应该太大来嵌套其他结构。同时，函数的缩进，不应该大于一个或者两个。该技巧可以使得代码更容易阅读理解消化。除此之外，我们也要使得函数内的语句处于同一个抽象程度。
在同一个函数中混合不同层次的抽象，会使得其令人迷惑，并且不利于管理。主程思考函数就像在讲故事一样，而非如何去写代码。
主程用其所选的编程语言的架构来构建一个更丰富，更有表现和更干净的代码块，就像一个完美的讲故事的人
注释并不能弥补劣质的代码
Venus Williams曾很好地说道：
“每个人有自己的注释，这就是谣言开始的方式”
注释就像两面刀。没有什么比得上放置妥当的注解。另一方面，没有比无聊无用的注解更浪费空间的。同时没有比传递错误信息的注解更具有破坏力的。
简而言之，注释至多是个必要的恶魔。为什么这么说？虽然不是一直但是大部分时候，注释越老，维护起来越困难，大部分程序员都因为不维护注释而臭名昭著。
代码移动和更改：代码块移动到其他地方，而注释不随着移动，就会成为一个问题！
要牢记，带有一点注释并且整洁和有表现力的代码，要远远好过复杂并带有大量注释的代码。不要浪费时间去解释你写的代码，而去投入时间去使其整洁。
“优先进行代码规范化”
Robert C. Martin有句话很正确：
“代码规范化是要去交流，而交流是一个专业的开发者首先要做的。”
上面这种说法是不能低估的，也是一名正真的伟大的开发者的最重要特征之一。 规范化的代码就像大脑的窗户。想要通过清晰的条理，细节的关注和明晰的想法来让人留下深刻印象。再看看代码，如果他们看到乱七八糟的代码，没有清晰的开头和结束，那么毫无疑问会会玷污我们的荣誉。
如果你觉得让代码工作是专业开发者的头等事情，那你离真相将更远。你现在创建的功能很有可能在下个版本中被替换，但你的代码可读性将不会改变。
在原始代码完全变得不能识别之后，代码的风格和可读性会持续的影响代码的维护。
要知道将来被记得的是你的代码风格，而几乎不是你的代码。所以你需要注意你的规范化并约束在整个小组的能理解简单的规范下。
书写你的”try-catch-finally”语句
Georges Canguilhem曾说：
“犯错是人类的本性，但是持续犯错就是穷凶极恶的”
解决错误是所有程序员都会做的。输入可能不正常，设备可能工作不正常。作为开发者，我们致力于让 代码的如期运行。然而，问题不在于解决错误，而是用干净可读的方式解决错误。
很多代码是由错误处理组成的。代码就变得如此分散，以至于完全磨灭了主代码的目的和逻辑。这是错误，彻底错误的。代码应该是整洁的、健壮的，可以用优雅的方式风格解决错误。这是一名伟大软件匠人的标志。
一个处理的方法是在try-catch语句中合理的闭合并捕获错误。这些块某种程度上也定义了你代码的作用域。当你在try-catch-finally语句中的 try部分执行代码的时候，就是在表明执行会在任意时刻终止，并在catch中恢复。
因为这个原因，写代码的时候从 try-catch-finally语句写起是个好的实践。这可以帮助你确定可以预期到的用户代码，不管代码在 try有没有报错。
牢记你的每次例外都应该包含足够的上下文来确定错误的来源和位置。在代码完成或者程序员离开组织后，创意性的错误信息会被长期记得
把它们放在一起
所以在这里总结一切的单词是什么？
答案是代码意识，在软件中相当于常识。
根据Robert Martin说的：“书写清洁的代码，就需要在疼苦的“清洁”感中，严谨的使用无数小技巧”。而这些小技巧统称代码意识。”
一些人生来有之，其他人就需要通过疼苦的坚持锻炼来获得。代码意识不仅可以帮助我们区分优秀的代码与劣质的代码，而且可以有助形成策略将劣质代码转换为优质的代码。
它用鲜明的词句表明了：仅仅是烘烤一个可爱的蛋糕是没有帮助的，如果你已经用狗屎给其上霜了。
这代码意识可以帮助程序员选择最好的工具，去指导他或者她努力创建一个更有价值的整洁漂亮的代码。
简而言之，一个有代码意识的程序员就如同一名画家一样，可以把空的画布变幻成一幅优美传世的杰出作品。
正如Harold Abelson总结道：
“程序员必须为了让人能阅读代码而书写代码，而机器执行只是顺便的。”
我理解的代码整洁之道
衡量好坏的标准
代码是人希望计算机去怎么做，而不是让计算机告诉人类它在做什么，前者是人能理解的语言，后者是神能理解的符号。
接触一个“新”项目的代码，如果觉的这堆代码烂，烂怎么个烂法？当阅读某一经典的开源项目，又感觉这些代码有不少可以学习的好，好又怎么个好法？
烂有烂的维度去考量，好也有好的标准去评判，之前谈起代码的质量时只是从质上定性其为好与坏，却没能从量上准确找出衡量的维度和标准。
标准包括圈复杂度，嵌套深度，变量跨度，设计模式，UT测试等等可数可量化的指标，依据可量化指标审查，这个好坏也便自然明了。
知道了考核的维度和标准，每个人应该去照做执行便可以，对不符合标准的代码可以去重构优化，对将要新生的代码按照标准去创造，但这要靠自觉和职业操守，这种执行是不一定可靠的软执行。
面对数以万行计的库存代码，仅靠人肉眼去审计和走查，这种行为在现代社会的“科技”公司里原始而又残忍。量体裁衣要有尺，竭泽而渔也得有网，衡量不仅要有标准也要有工具。而工具的执行，像SourceMonitor、Sonar等业界普遍使用的工具去自动化扫描、发现和反馈，这种执行才是可靠的硬执行。
能够被可靠执行的标准才算是标准。
重构清晰代码的技能习惯
没有人一开始就能写出优美散文一样的代码，整洁的代码是用心重构出来的。
不清晰的代码总是会触犯标准，对临床医学来讲病人生什么病，开什么处方，吃什么药是有章可循的。坏代码违反整洁标准的哪一条，就使用哪一条的处方来修改。这个修改的处方和药是可以积累和总结的，而且有已经总结好的经验。剩下的是学习和养成习惯。
对已有代码的整洁化不是大范围的重写，是在保证不影响已有功能的前提下坚持做的改进优化。
唯有源头活水来，甲严格执行整洁之道的准则，乙坚持己见，丙随意而为，即使甲有熟练的整洁技能和习惯也改不完项目的所有问题。
对编程来讲，一个人的习惯是能力，一个团队的能力才是习惯。
趋向美的专业态度
没有场景做铺垫的性能优化是一种浪费，没有测试做保证的代码修改是一种盲目。准则都是经过符合场景的测试总结出来的，是一种专业的产出。
有正确价值观的开发者应该在接到新需求变更，故障修复的任务时，先用心想一想怎么不破坏或者少影响已有架构和代码的前提下去进行，而不是简单粗暴的将新代码塞进去，多一分钟的思考就多一份整洁，版本的交付压力，Manager的催促不该成为潦草执行的理由，编写代码重要的不只是考虑机器的语法，更要注重人类沟通的语法。价值观和底线不是要成为绑架程序员和团队成员操守和品行的枷锁，只是作为专业人员，每一行代码都要一心一意，专注，怀着谦卑和敬畏的心态去设计去编写。
