本文属于原创文章,转载请注明--来自桃源小盼的博客

前言

虽然这个系列是前端规范,但是我的理解稍稍不同。

  • 代码格式:具体到换行,符号,空格等每一个细节
  • 代码规范:一定要这么做
  • 最佳实践:最好要这么做

代码格式自然是让prettier来做。

这个系列是代码规范和一部分最容易实施的最佳实践的组合。

1.优先使用es6+新语法

  • 解构赋值
  • class类
  • 箭头函数

    • 函数参数默认值
    • 可选链 ?.

只列出了部分特性,es6+的语法,表达性更好,如果还没学会或者不习惯。

那就强迫自己去学习和习惯,然后你就喜欢上了它。

2.函数必须添加多行注释

例外情况:生命周期函数

/**
 * 发起批量处理
 */
function launchBatch() {
  batching.value = true
}

其实最好的注释,就是依赖方法命名和方法参数命名来表达含义。

但现实是每个团队的情况都不同,国人英文素质普遍谈不上好,所以不能仅仅依靠方法命名。

所以我们在第一版的规范中规定,如果开发中个人认为这个函数名不容易理解,那么需要增加注释。如果函数参数值多样,也需要注释说明。

然而真实的情况是,每个人觉得自己的函数命名易懂,所以几乎没有注释。所以这一次才要求所有函数必须注释。

3.函数长度一般控制在20行以内

为什么是20行?综合多种因素吧。个人的经验、易维护程度、模块化。

其实20行就是个风向标,如果真的就是21行,就说这段代码不好吗?

自然不是,这条规范是在提醒每一个开发者,超过20行的时候,重新审视这段代码。

当然了,有的代码就算10行以内,也不是好代码。

4.函数参数超过二个可以改为参数对象

const item = await getItemFromCollection(54391, 'shop')

// better
const item = await getItemFromCollection({
  id: 54391,
  collectionName: 'shop',
})

async function getItemFromCollection({ id, collectionName }) {
  // do something
}

参数对象的方式,从调用者的角度,更容易理解参数的含义,相当于在调用这里,就帮助我们做了参数命名。否则我们就要去函数定义的地方,查看相关的说明。

5.函数参数不要定义为boolean类型

6.尽量不使用switch case

7.用卫语句替换嵌套的条件表达式

// bad
function getPayAmount() {
  let result
  if (isDead) {
    result = deadAmount()
  } else {
    if (isSeparated) {
      result = separatedAmount()
    } else {
      if (isRetired) {
        result = retiredAmount()
      } else {
        result = normalPayAmount()
      }
    }
  }
  return result
}

// good
function getPayAmount() {
  if (isDead) {
    return deadAmount()
  }
  if (isSeparated) {
    return separatedAmount()
  }
  if (isRetired) {
    return retiredAmount()
  }
  return normalPayAmount()
}

8.多字符串拼接使用模板字符串

// bad
const str = 'a' + 'b' + test

// good
const str = `ab${test}`

9.优先使用迭代器遍历

10.循环嵌套三次的时候,复杂度为O(n^3),注意性能问题

如果想更好地处理这类问题,还是需要组内伙伴都具备算法知识。

只不过现实情况通常不同,考虑到很多人缺乏算法知识,所以有了这一条。

还是那句话,没有最好的规范,只有适合与更好的规范。

11.业务相关的数字,需要定义常量

// bad
if (type === 1) {
    // doSomething
} else if (type === 2 ) {
    // doSomething
}

// good
const MANAGER = 1
const GENERAL = 2

if (type === MANAGER) {
    // doSomething
} else if (type === GENERAL ) {
    // doSomething
}

12.this转换命名self

13.工具函数优先使用lodash

推荐使用lodash-es库,为了webpack的tree shaking优化体积。

14.特殊业务逻辑要增加单行注释

特殊的业务,通常能记住的情况因人而异,有可能你一直记着这个特殊的业务逻辑,有可能你在一周后就忘记了。为了团队,也为了未来的自己,写好记录。

15.尽早删除TODO注释

16.过期代码及时删除

真想找回,可以查看git历史记录。

17.尽早删除调试console.log语句

如果在代码里写了很多的调试语句,也许是调试代码的方式不够好,试试debugger方式。

18.特殊情况

  • 在for循环中使用i是合适的
  • 在变量交换中使用temp是合适的

参考资料

  • 《重构》
  • 《代码整洁之道》
  • 《代码之丑》

桃源小盼聊技术
733 声望16 粉丝

努力做到优秀。