五、好代码的标准

1. 代码水平如何衡量？

   我很多时候都在想什么样的代码是好代码，什么样的系统是好的系统。一个完全没有 bug 的系统是不存在的。我想一个好的系统是可调试的、可扩展的、可配置的，好的代码是可读的、鲁棒性强的、松耦合的、可测试的、可以快速定位的。 可以运行，没有故障的系统肯定是好的系统。但是没有故障几乎是不可能的，我觉得好系统的另一个指标就是出故障了能够快速找到问题代码，并且能够快速进行故障恢复。 而我们在设计系统或者写代码的时候就要考虑这些因素，好的代码其实很多时候就取决于写代码那个人的代码素养。|

2. 什么是代码素养？

   很简单的一个数学问题，4的平方根是多少？有多少人会回答2呢？

   写代码也是一样，很多人都只会考虑一种情况，这其实不是智商也不是能力问题，只是考虑问题的时候是否严谨。当你告诉他这个地方需要判空，那个地方需要加 try catch 的时候，他往往不以为然，觉得这只是一时没考虑到而已。

   很不幸，这种素养很难短时间内养成，而这种没有代码素养的人，写大项目或者复杂系统，写出来的代码将是灾难。

   就像一堆沙子，你把水倒进去，你根本不知道哪里在漏水，但是到处都在漏水，水一下子就没了，你只能推翻重写。而好的代码应该像一块铁板，水倒上去滴水不漏。

   代码素养只能靠平时慢慢积累，多看别人是怎么处理细节的，自己写完代码后多想想 test case，多多测试。

   代码水平绝对不是会多少种语言，会多少个框架。而是你在写代码的时候的种种思考，对细节的处理，对各种情况的判断，代码的清晰程度等等。

   所以，你的代码水平提升了吗？

   1. 统一的编码规范

   编码规范往简单说其实就是三个方面：

   1. 换行
   2. 空格
   3. 变量命名

   放在 PHP 里面，还有一些附加的地方，比如关键字大小写，语法糖的使用（array()与[]等）的问题。之前整理过PSR的标准，也找过php-cs-fixer这样的工具。这些都是规范代码的重要手段。有统一的标准，配合上工具的检查，形成统一的编码约束不是什么难题。

   没有规范，不同的人甚至同一个人在空格、换行和命名上都有可能是十分随意的。代码一长，回使整个文件看起来无比杂乱。

   典型的例子比如：if和else的组合，可以写出无数种风格，比如：

   <?php # 单语句不写大括号 if (true) doSomething(); # else 大括号换行 十分占篇幅 if (true) {     doSomething(); } else {     doElseThings(); } # 此外还有关键字后不带空格，随意缩进等等 # ... 
   

   再比如变量函数命名的问题上，各种混搭风格层出不穷：

   <?php # 全小写 $someparam1 = null; # 首字母下环线 $_some_param_1 = null; # 某些库的类，下划线和大小写混用 class Abstract_ClassA {  } 
   

   这里并不探讨各种写法的优缺点，只是风格需要保持统一，不要混用。

   2. 良好的编码习惯

   如果你仔细看过 PSR 的标准，可能也会注意到某些地方其实是标准无法涉及到的。比如一个超长的表达式在什么时候换行，如何缩进等。

   这里涉及到的就是编码习惯的约束问题。

   比如方法的链式的调用的问题，比如某些数据库查询的封装：

   <?php # 不换行的情况下句子会很长 $result = $this->db->select('id')->where('a', 1)     ->groupBy('a')->orderBy('id', 'DESC')->result();  # 这种情况下我建议是一个条件一行，保持缩进 $result = $this->db->select('id')     ->where('a', 1)     ->groupBy('a')     ->orderBy('id', 'DESC')     ->result(); 
   

   还有数组定义，某些数组成员字符串很长的情况下的写法：

   <?php $array = ['abcdefg', 'acbdfeg', 'bcadgfe', 'cdadgef'];  # 如果成员太长，我建议拆解，这样 $array = [     'abcdefg',     'acbdfeg',     'bcadgfe',     'cdadgef', ]; 
   

   3. 寻找最优的写法

   写代码的过程中，最优的写法和编码习惯又不是同一件事情。这里要说的指的是如何遵循 PHP 的语言特性或者框架的特征，充分发挥语言和框架的能力来减少冗余。

   比如在获取前端传入的参数的时候，很多时候能见到这样的代码：

   <?php $param = isset($_POST['param']) ? $_POST['param'] : ''; 
   

   更有甚者一些框架将前端传入的参数封装了一层，比如$this->request->data['param']，如果再去用isset或者array_key_exists判断，整个获取参数的语句就会变得很长。

   某些情况下使用三元运算符的时候需要注意?:是可以合并使用的。

   其实我们应该去尝试封装这种写法，防止同样的变量出现在一个语句中多次的情况。对于默认值的赋予，可以调研框架是否有封装提供，或者通过强制类型转换的方式进行。

   还有一种情况是条件和循环嵌套的时候。比如从数组里抽取某一个字段，或者对某一个字段的值进行处理的时候，善用array_map以及引用（&）往往能节省不少工作量。但是使用的时候也要注意数组指针最后的位置。

   在根据条件返回结果时，需要善用return。还有就是合理的抽象与封装。

   4. review 自己的代码

   除了以上提到的在日常开发中需要注意的一些问题。还有就是事后的工作。

   我相信很多人在看自己以前的代码的时候都有一种其实有更好的写法的感觉。随着时间的推移自己总会有更丰富的阅历，更多的想法。偶尔 review 自己的代码也是对过去的总结，也许会有新的感知。

   5. 推广给你的队友

   团队项目中，队友的配合对整个代码的规范起着决定性的作用。一个团队中有一个人不遵守规范，而又要到处修改代码的时候，很快就能破坏到所有的约束。

   有统一的标准，有良好的执行力才能完成这件工作