代码整洁之道-六虎

人最大的痛苦，便是无法跨越知道和做到的距离 ——罗翔

该篇不写那些费脑的硬常识点了，聊点认知方面，些许轻松点的话题： 代码整齐之道。

对本职工作认真负责，是一种基本素养，对于一线正在撸代码的程序员，写好代码是一种本分，所以给我个人给本篇再加一个副标题—— 程序员工作素养。

引子

编程文明拥有悠久的历史，这个话题也被前辈们广泛讨论过，自己也在不同场合中和朋友、搭档零零碎碎的聊过一些，还在某乎上答复过几个问题，之所以再正式的聊这个话题，是由于在近期我司产品研发部总监做了一次共享，叫做代码整齐之道，听完仍是有所牵动。

声明：该篇不是照本宣科，是《代码整齐之道》+ 总监的技术共享 + 自身工作经历结合。

在座有多少人读过此书？我认为这本书应该是所有程序员都需求去读的。
有谁曾为自己写了一段好的代码沾沾自喜？
又有谁在过了许久看自己之前写的代码有过感触：写的依旧不错/糟糕透顶？

这是来自共享开篇的一些提问，不知是否牵动了各位读者，咱们也能够在心中答复一下，沉思过后信任各位读者会有些话要说，对于现已手撸千万行的你，也一定有自己的一套“代码整齐之道”，咱们不妨一同走过下文，在这过程中比照一下你心中的“道”。

本文目的：重温一些代码整齐之道，希望能够给日常撸事务的你带来一些动力/兴致/小幸福。

为什么要写整齐的代码

说这个问题，咱们反向的想一下，面临不整齐的代码会怎么样（“屎山”），是不是有很多话想说，我来起个头，说一下自己曾吐槽过的（代码就不上图了）：

这么杂乱的逻辑，变量/函数姓名给个缩写，你让咱们猜它是谁/干啥呢？
js 里一个函数有 7、8 个参数，又没类型，光看调用来回切换要花十几分钟，闹呢？
一个函数放好几百行代码，让我来回切换，你是怕我得颈椎病啊？
在一些底层核算呈现莫名的数值，不明不白的就加上或减去一个数字，咱也不知道它表达的啥？
if 判断的条件，直接写核算表达式或函数，能有个 4、5 行，每次看这段代码都要花很长时刻，还总是出 bug，这不当妥的“雷区”？
这注释分明写的是 a 逻辑，成果下面代码写的是 b 逻辑，坑啊…
如出一辙的代码，复制 n 遍，写这段代码的脑子有坑吧。
一个函数分明写的是 getXXX，成果里边改原始数据？出 bug 找半响，nm。
……

所以，写出整齐的代码便是防止少呈现以上呈现的状况，能够总结为以下几条：

更具可读性
更节约时刻、更高效
更易保护
更具扩展性
更易重用
更简单测试

命名

命名是程序界一级难题

起一个好的姓名，至关重要，但并不简单，我常常为了起一个好的姓名抓耳挠腮的，有时分跟协作的人会 battle 半响，咱们需求建立一个认知： 在久远来看，花费大量时刻来挑选一个好姓名是值得的，由于它所带来的价值或节约的时刻远远超过了起名所花费的时刻 。

起姓名也分几个等级：

最基本的也是见名知意
好一点的能够更恰当的体现事务
再高档一点的能够覆盖领域的概念

有爱好咱们能够看下，《架构师修炼之道》提出对的 7 个阶段，以及怎么提炼一个好的姓名，下图是之前截的片段

假如要写全关于怎么命名我怕是再写上 1000 字也不一定够，所以下面只写一些比较简单做到的，也是最基本的底线：

姓名尽或许具体些（不要怕长），少用缩写 ，除非是咱们一致的（JDBC、XML）

    // bad
    const act = 1; // 不清楚是 active 仍是 action
    function recursion() {}; // 只知道递归，可是不知道为什么要递归
    // good
    const action = 10;
    function getAllChildrenByNodes() {}

尽或许起一些简单的单词，最好能读出来，能写出来，简单记住的常规单词 ，幻想一下，搭档之间讨论读不出来这个单词的尴尬场景，记得之前做的一个商城项目，搭档在规划表的时分用了一个单词 integration ，这个单词的本意是数学中的积分，而事务中实际上表达用户积分。这里有一份软件开发常用词汇表：这里
变量用名词或形容词 + 名词，函数名用动词 + 名词或动词 + 形容词 + 名词，类名用名词

    function calculateTotalPrice(){} // 核算总价
    function validateUserPermission(){} // 验证用户权限
    const customerName = "zhangsan"; // 客户姓名
    const recentOrders = [] // 最近的订单
    class PermissionBuilder() {} // 权限结构器

布尔值或函数用 is 或 has 开头，能优先用必定，不要用否定，更不要用两层否定表示必定 ，这很不高效

    // bad
    isNotVisible = true;
    // good
    isVisible = false;
    // bad
    isNotInvisible = true; // 不是不行见的，表示可见的
    // good
    isVisible = true;

函数

函数尽或许的短小 ，有爱好看一些知名函数编程的库： Lodash 。
参数尽或许的少 ，最佳状态是没有参数，其次是 1 个、2 个、3 个，理论上最好不要超过 3 个，不过具体仍是要根据实际场景，有些状况下也难以防止。
遵从单一原则，一个函数只做一件事 。一个判断的小技巧：尝试幻想对一个函数做单元测试，每能够测的一点就能够罗列一个函数。
参数最好不用布尔值，在参数多的状况最好运用对象替代 ，由于每次调用时都需求看一下原函数的参数是什么，顺序也要对照好，扩展也不方便，会越来越长。示例：

    function getUsersByIds(ids: string[], isDeleted?: boolean, isArchived?: boolean){}
    getUsersByIds([], true, true);
    // good
    function getUsersByIds(ids, options: {isDeleted?: boolean, isArchived?: boolean}) {}
    getUsersByIds([], { isDeleted: true, isArchived: true})

函数尽或许不要依靠上下文 ，这点能够按照纯函数原则。
函数名、签名和函数逻辑和回来值有必要保持一致， 挂羊头卖狗肉的行为非常可气，误导比读不明白代码更可怕，比方：

    // 这个函数本意只是验证用户名是否合法，成果内部却包括修正用户信息的逻辑
    function verfiyUserName(user) {
      const regexp = /^[a-zA-Z0-9_-]{3,16}$/;
      if(regexp.test(user.name)) {
    	user.name = 'legal_' + user.name;
        return true;
      } else {
      	return false;
      }
    }
    const user = {id: 1, name: 'zhangsan' };
    const result = verfiyUserName();

函数不要发生副作用，尽或许不要改动原数据或上下文数据，运用不行变数据（Immutable Data） ，js 中也有一些让人诟病的原生函数，比方 sort、reverse、splice 等 ， 能够 filter 、map 或解构替代

    const users = [
      {id: 2, name: '张三'},
      {id: 1, name: '李四'},
      {id: 3, name: '王五'}
    ];
    // 从用户列表中删去姓名是王五的元素
    const newUsers = users.filter(x=> x.name !=='王五');
    // 按照 id 排序
    const newUsers = [...users].sort((a, b) => a.id - b.id);