编码基本原则

  • 易读性优先，「无歧义」优于「简洁」
  • 如果不是性能瓶颈，就不要为了性能而改写代码
  • 复杂性守恒原则：无论你怎么写代码，复杂性都是不会消失的

推论：如果逻辑很复杂，那么代码看起来就应该是复杂的。如果逻辑很简单，代码看起来就应该是简单的。

命名

程序员三大难题

  • 变量命名
  • 缓存失效
  • 边界判断

可见变量命名的重要性。

网上有很多命名规范参考。本文只总结基本原则。

注意词性

普通变量/属性用「名词」

  1. const person = {
  2.     name: 'Sean'
  3. }
  4. const student = {
  5.     grade: 3,
  6.     class: 2
  7. }

布尔变量/属性用「形容词」或者「be动词」或者「情态动词」或者「hasX」

const person = {
    dead: false, // 如果是形容词，前面就没必要加 is，比如isDead 就很废话
    canSpeak: true, //情态动词有 can、should、will、need 等，情态动词后面接动词
    isVip: true, // be 动词有 is、was 等，后面一般接名词
    hasChildren: true, // has 加名词
}

普通函数/方法用「动词」开头

const person = {
    run(){}, // 不及物动词
    drinkWater(){}, // 及物动词
    eat(foo){}, // 及物动词加参数（参数是名词）
}

回调、钩子函数用「介词」开头，或用「动词的现在完成时、一般将来时」

const person = {
    beforeDie(){},
    afterDie(){},
    // 或者
    willDie(){}
    dead(){} // 这里跟 bool 冲突，你只要不同时暴露 bool dead 和函数 dead 就行，怕冲突就用上面的 afterDie
}
button.addEventListener('click', onButtonClick)
const component = {
    beforeCreate(){},
    created(){},
    beforeMount(){},
    mounted(){},
    beforeUpdate(){},
    updated(){},
    activated(){},
    deactivated(){},
    beforeDestroy(){},
    destroyed(){},
    errorCaptured(){}
}

容易混淆的地方加前缀

div1.classList.add('active') // DOM 对象
div2.addClass('active') // jQuery 对象
// 不如改成
domDiv1 或 elDiv1.classList.add('active')
$div2.addClass('active')

属性访问器函数可以用名词

$div.text() // 其实是 $div.getText()
$div.text('hi') // 其实是 $div.setText('hi')

注意一致性

介词一致性

如果使用了 before + after，那么就在代码的所有地方都坚持使用
如果使用了 before + 完成时，那么就坚持使用
如果改来改去，就「不一致」了，不一致将导致「不可预测」

顺序一致性

比如 updateContainerWidth 和 updateHeightOfContainer 的顺序就令人很别扭，同样会引发「不可预测」

表里一致性

函数名必须完美体现函数的功能，既不能多也不能少。
比如：

function getSongs(){
    return $.get('/songs).then((response){
        div.innerText = response.songs
    })
}

就违背了表里一致性，getSongs 表示获取歌曲，并没有暗示这个函数会更新页面，但是实际上函数更新了 div，这就是表里不一，正确的写法是：

要么纠正函数名

function getSongsAndUpdateDiv(){
    return $.get('/songs).then((response){
        div.innerText = response.songs
    })
}

要么写成两个函数

function getSongs(){
    return $.get('/songs)
}
function updateDiv(songs){
    div.innerText = response.songs
}
getSongs().then((response)=>{
    updateDiv(response.songs)
})

时间一致性

有可能随着代码的变迁，一个变量的含义已经不同于它一开始的含义了，这个时候需要及时改掉这个变量的名字。
这一条是最难做到的，因为写代码容易，改代码难。如果这个代码组织得不好，很可能会出现牵一发而动全身的情况（如全局变量就很难改）。

改代码

如果代码有单元测试，那么改起来就很放心。如果没有单元测试，就需要用「小步快跑」的策略来修改。
小步快跑的意思是说，每次只修改一点点，测试通过后，再修改一点点，再测试，再修改一点点……如此反复。

这里总结两个经久不衰的方法

使用函数来改代码

步骤：

  • 将一坨代码放到一个函数里
  • 将代码依赖的外部变量作为参数
  • 将代码的输出作为函数的返回值
  • 给函数取一个合适的名字
  • 调用这个函数并传入参数
  • 这个函数里的代码如果超过 n 行（可以自己定个标准，5 行，10 行），则依然有优化的空间，请回到第 1 步

使用对象来改代码

如果使用了函数改造法改造后，发现有太多的小函数，则可以使用对象将这些函数串起来。
「this 是函数和对象的桥梁」，用 this 来串联这个对象和所有函数。
示例

一些固定的套路

表驱动编程（《代码大全》里说的）

所有一一对应的关系都可以用表来做

自说明代码（以 API 参数为例）

把别人关心的东西放在显眼的位置

语言特性

JS 从诞生到发展至今，已经超出了 Brendan Eich 的预期，况且 JS 起初只是短短一周内的造物，遗留下了一些 not good parts 也能理解。
语言特性使用的原则就是：不使用易产生歧义的特性，如 var，全局变量等等。

质量意识

广为流传的错误观点

  • 我们没有时间写单元测试 没时间写测试，有时间改 bug
  • 应该给每一行代码注释 正确地写注释，写 why 而不是 how
  • 代码中的空格、括号很重要 空格、括号远没那么重要
  • 等有时间了再重构 重构要每天进行
  • 只要坑挖得足够多，就能筑起护城河 只要坑挖得够深，头发会掉的更快
  • 测试是 QA 的事而与开发无关 我们应该能独立保证自己代码的质量，不要完全依赖测试人员

bad smell（坏味道）

有些代码可以用，但是很「臭」。
哪些代码是有坏味道的：

  • 表里不一的代码
  • 过时的注释
  • 逻辑很简单，但是看起来很复杂的代码
  • 重复的代码
  • 相似的代码
  • 总是一起出现的代码

现状与破局

  • 大部分程序对质量的提升方法是堆时间
  • 正确的办法是自动化、监控、预警
  • 大部分程序员对代码质量还停留在 Lint 工具
  • 正确的做法是静态分析、单元测试、不断及时重构

我们不应该被周围同化，只简单地满足于增删改查。应该了解什么是好的、能提升效率的，然后尽可能地实践测试、自动化：一切能用机器做的事情，都应该交给机器。

破窗效应

此理论认为环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象，就是犯罪心理学中的破窗效应。

破窗效应完全符合熵增定律，我们要做那个外力：只要是经过我们手的代码，就会比之前好一点。

业界代码规范

谷歌 JS 代码规范
Airbnb JS 代码规范
JS 标准代码样式

参考

如何写出无法维护的代码
The Joel Test: 20 Years Later
Douglas Crockford – The better parts
代码大全
重构