编写可读代码的原则

       正因为缺乏用艺术的心态去审视，所以对于那些长达几百行的函数，跨越上百行的变量，但支撑系统运行了好长时间的代码，我们只是默默吐槽。对于自身，时隔几周再回过头再看自己的代码，如同《重构》里所说，依然能感受到那股难闻的气味。不得不膜拜那些大师能把这些看似杂乱无章的操作总结成这样简洁优雅的思想。
      《重构》与《编写可读代码的艺术》都是关于编码的好书，但是侧重点还是有些不同，前者更多关于如何设计和重构类与方法，让代码架构能够更好地维护与扩展，而后者更关注如何让写出来的代码更易懂，其实这样也是更利于维护。
        为什么要编写可读的代码，一定要有深刻的认识：维护一段代码的时间远大于开发它的时间，即使是开发者本身在几个星期之后也常常不知道自己写的是什么就更不用指望其它维护者了，因此代码一定要是易于理解的。
        总结一下此书一些重要的准则，可以大大提高代码的易读性：
        1.关于名字，起一个好的名字很重要，无论是变量名还是函数名，选择一个好的名字可以承载很信息，某种程度上是一种更好的注释。在代码里，名字应该尽量精确、专业、不要有多余，如我们应该考虑是fetchXXX还是downLoadXXX,而不是getXXX, 不要有tmp，var，应该使用$order->id而不是$order->orderid，等等。有一个重要的原则是不能太长，这样读起来也会吃力，于是我们常常会为名字简单同时又要精确而感到纠结，说明起个好名字不是简单的事，如同北邮人论坛上各种为小孩征名字的热门帖子。
        2.关于审美，如同好的杂志版面让人伤心悦目，使用一致的布局和规范，让相似的代码看上去相似，把相关的代码行分组，行程代码块，
        3.关于注释，首先不要为了注释而注释，某种程度上，因为需要注释常常因为它不是很好读，这个时候应该先考虑你的函数名和变量名是不是应该改改。应该注释的地方：为什么是这样而不是那样，代码中的缺陷，读者意料之外的行为等。要写出好的注释，应该使用精确的词（避免it，this等），尽量精确描述函数行为，声明高层次的意图而非细节，适当使用输入/输出例子，解释难以理解的参数
        4.关于循环和逻辑，应该最小化代码中的’思维包袱’，先处理正逻辑、简单、有趣的情况，减少分支循环嵌套，用提早返回减少分支
        5.关于表达式，越长的表达式越难以理解，可以考虑使用易懂的解释变量或封装成函数，尽量少用三目运算符，少用电路逻辑的特性，如 isEmpty && doSomethine
        6.关于变量，变量当然是越少越好，太多则难以跟踪它们的动向，要去掉那些临时变量、中间结果、控制流变量。缩小变量的作用域，让你的变量对尽量少的代码可见，防止命名空间污染。只写一次的变量更好，不断变化的值让人难以理解，跟踪这种变量的值很有难度，只设置一次的变量更好理解。
        7.关于重构，在这里如果要深入，建议读《重构，改善既有代码的设计》。此书主要从可读性的角度进行概括，最简单的就是抽取子问题(extract method),这样更容易理解、更好地实现通用。让函数一次只做一件事（我觉得这个也还是需要extract method)