关于前端:代码质量第-3-层-可读的代码

点击一键订阅《云荐大咖》专栏，获取官网举荐精品内容，学技术不迷路！

可读的代码能极大的进步开发效率。在开发的过程中，有很大一部分工夫是在浏览代码。可读的代码，容易了解，也容易改。反之，不可读性的代码，读起来情绪很差，改起来也容易出错。

上面是一段不可读读的代码：

const user = ...
const foo = (cb) => ...
const bar = (list, cb) => ...
const other = (list1, list2) => ...

if(user ? user.isAdmin : ((user.permission && user.permission.view) ? user.permission.view === true :  false)) {foo((res) => {if(res && res.ok && res.list && res.list.length > 0) {bar(res.list, (res2) => {if(res2 && res2.ok && res2.list && res2.list.length > 0) {other(res.list, res2.list)
        }
      })
    }
  })
}

以上代码有这些问题：

函数的命名和性能不符。
if 条件太简单，而且嵌套深。
回调函数嵌套深。

将下面的代码改成可读的代码：

const user = ...
const fetchChannel = () => ...
const fetchArticle = (list) => ...
const render = (channelList, articleList) => ...

const hasViewPermission = user.isAdmin || user.permission?.view
if(!hasViewPermission) {return}

const {ok, list: channelList} = await fetchChannel()
if (!(ok && channelList?.length > 0)) {return}

const {ok: fetchArticleOk, articleList} = await fetchArticle(channelList)

if (!(fetchArticleOk && articleList.length > 0)) {return}
render(channelList, articleList)

总结来说，可读的代码次要有如下的特点:

统一的代码格调。
正当的命名。
必要的正文。
没有大文件。
没有嵌套很深的代码。

写出可读代码，要满足下面提到的特点。

统一的代码格调指：空格，缩进，命名格调 (驼峰，中划线等) 等在整个我的项目里是统一的。统一的代码格调，看起来很参差，也能缩小了解老本。在我的项目中，用怎么的代码格调不重要。重要的是，格调要统一。
前端业界比拟有名的代码格调有：Airbnb JavaScript Style Guide 和 JavaScript Standard Style。不想折腾的，能够应用 JavaScript Standard Style。JavaScript Standard Style 的特点：

毋庸配置。史上最便捷的对立代码格调的形式，轻松领有。
主动代码格式化。只需运行 standard --fix 从此和脏乱差的代码说再见。
提前发现格调及程序问题。缩小代码审查过程中反反复复的批改过程，节约工夫。

确定了代码格调后，能够用查看工具 ESLint 来保障代码格调的对立。每次代码提交前，做查看，能够用工具：husky。对于大我的项目，查看整个我的项目太慢。用 lint-staged 只查看本次改变的文件。

There are only two hard things in Computer Science: cache invalidation and naming things. 计算机科学中只有两件事很难：缓存生效和命名。— Phil Karlton

好的命名是“看其名而知其意”。具体来说，好的命名有如下特点:

直白的，有意义的
好的命名是易于了解的，也就是直白的，有意义的。比方：fetchUserInfo。
举荐：故宫命名法
提取指标对象的要害特色来命名。
举荐命名工具：CODELF。它帮你搜寻 Github、GitLab 等网站中，你想查找的内容的不同命名。
留神，命名中的单词不要拼错。举荐单词拼写查看工具：Code Spell Checker。

遵循行业常规
好的命名也应该遵循行业的习惯常规。如：业界常规 id 作为惟一标识命名，不要用 identifier。i、j、k 用来做循环计数变量命名。

合乎代码格调
好的命名应该合乎以后我的项目的代码格调。如：驼峰格调等。

不好的命名有如下特点:
无意义的名字
无意义的名字，如：foo, bar, var1, fun1。

太过形象的名字
太过形象的名字，如：data，res，temp，tools。

会有歧义的简称
会有歧义的简称，如：mod。你可能无奈确认到底是 mode 或 module。

不必要的上下文信息

// bad
function async getUserName (userId) {const userName = await fetchUser(userId)
  return userName
}

// good
function async getUserName (id) {const name = await fetchUser(id)
  return name
}

太长的名字
太长的名字，不容易了解。如：fetchGraintYoungestBoyName。优化形式：将不重要内容省略掉。如改成：fetchBoyName。

正文是是对代码的解释和阐明。好的代码是自我解释的。对于不简单的代码，不须要正文。如果写的正文，只是解释了代码做了什么，不仅节约读者的工夫，还会误导读者（正文和代码性能不统一时）。

须要写正文的场景：

当代码自身无奈清晰地论述作者的用意。
逻辑比较复杂。

大文件指：代码行数很多 (超过 1 千行) 的文件。大文件，象征代码做了很多事，很难跟踪到底产生了什么。

能够用 ESLine 中 max-lines 规定来找出大文件。
优化计划：按性能，将大文件拆分成若干小文件。

嵌套很深的代码，可读性很差，让人产生“敬畏感”。比方:

fetchData1(data1 =>
  fetchData2(data2 =>
    fetchData3(data3 =>
      fetchData4(data4 =>
        fetchData5(data5 =>
          fetchData6(data6 =>
            fetchData7(data7 =>
              done(data1, data2, data3, dat4, data5, data6, data7)
            )
          )
        )
      )
    )
  )
)

上面是几种常见的嵌套很深的场景。
1. 回调天堂
用回调函数的形式来解决多个串行的异步操作，会造成嵌套很深的状况。俗称“回调天堂”。如:

fetchData1(data1 =>
  fetchData2(data2 =>
    fetchData3(data3 =>
      done(data1, data2, data3)
    )
  )
)

2.if 嵌套很深
在条件语句中，如果判断条件很多，会呈现嵌套很深或判断条件很长的状况。比方，判断一个值是否是: 1 到 100 之间，能被 3 和 5 整除的偶数。这么写:

const isEvenNum = num => Number.isInteger(num) && num % 2 === 0
const isBetween = num => num > 1 && num < 100
const isDivisible = num => num % 3 === 0 && num % 5 ===  0

if (isEvenNum(num)) { // 是偶数
  if(isBetween(num)) { // 1 到 100 之间
    if(isDivisible(num)) { // 能被 3 和 5 整除
        return true
    }
    return false
  }
  return false
}
return false

三元表达式也会呈现嵌套很深的状况：

a > 0 ? (b < 5 > ? (c ? d : e) : (f ? g : h)) : (i ? j : k)

3. 函数调用嵌套
执行多个函数调用，每个函数输入是下个函数的输出，会造成很深的嵌套。如:

// 模仿炒蛋的过程：买蛋 -> 打蛋 -> 炒蛋 -> 上桌。toTable( // 第四步: 上桌
  fry( // 第三步: 炒蛋
    handle( // 第二步: 打蛋
      buy(20) // 第一步: 买蛋
    )
  )
)

4.React 高阶组件嵌套
在 React 写的利用中，会呈现一个组件被很多个高阶组件 (HOC) 包裹，造成嵌套很深的状况。如:

class Comp extends React.Component {...}

Wrapper5(
  Wrapper4(
    Wrapper3(
      Wrapper2(Wrapper1(Comp)
      )
    )
  )
)

5.React Context 嵌套
在 React 写的利用中，能够用 Context 来治理子组件间的数据共享。如果共享数据很多，而且类型不同，容易造成顶部组件 Context 嵌套很深。如：

<PageContext.Provider
  value={...}
>
  <User.Provider
    value={...}
  >
    <Project.Provider
      value={...}
    >
      <ChildComp />
    </Project.Provider>
  </User.Provider>
</PageContext.Provider>

优化计划见：这里。

合乎本文提到的可读代码特点的代码，可读性都不会差。当然，还有很多能晋升代码的可读性的技巧。比方：

限度函数的参数数量。
限度函数的圈复杂度。
禁用 with 语句。
要理解更多晋升代码可读性的技巧，举荐撸一遍 ESLint 的规定。

代码品质的下一档次就是：可复用的代码，将会在下一篇文章中介绍。

聊聊代码品质 –《学得会，抄得走的晋升前端代码品质办法》前言
代码品质第 5 层 – 只是实现了性能 **
代码品质第 4 层 – 强壮的代码

《云荐大咖》是腾讯云加社区精品内容专栏。云荐官特邀行业佼者，聚焦于前沿技术的落地及实践实际之上，继续为您解读云时代热点技术、摸索行业倒退新机。点击一键订阅，咱们将为你定期推送精品内容。

关于前端:代码质量第-3-层-可读的代码

如何写出可读代码?

一、统一的代码格调

二、正当的命名

三、必要的正文

四、没有大文件

五、没有嵌套很深的代码

总结

金伟强往期精彩文章举荐：