并发
用 Promises 替代回调
回调不够整洁并会造成大量的嵌套。ES6 内嵌了 Promises,使用它吧。
反例:
正例:
Async/Await 是较 Promises 更好的选择
Promises 是较回调而言更好的一种选择,但 ES7 中的 async 和 await 更胜过 Promises。
在能使用 ES7 特性的情况下可以尽量使用他们替代 Promises。
反例:
正例:
错误处理
错误抛出是个好东西!这使得你能够成功定位运行状态中的程序产生错误的位置。
别忘了捕获错误
对捕获的错误不做任何处理是没有意义的。
代码中 try/catch
的意味着你认为这里可能出现一些错误,你应该对这些可能的错误存在相应的处理方案。
反例:
正例:
不要忽略被拒绝的 promises
理由同 try/catch
。
反例:
正例:
格式化
格式化是一件主观的事。如同这里的许多规则一样,这里并没有一定/立刻需要遵守的规则。可以在这里完成格式的自动化。
大小写一致
JS 是弱类型语言,合理的采用大小写可以告诉你关于变量/函数等的许多消息。
这些规则是主观定义的,团队可以根据喜欢进行选择。重点在于无论选择何种风格,都需要注意保持一致性。
反例:
正例:
调用函数的函数和被调函数应放在较近的位置
当函数间存在相互调用的情况时,应将两者置于较近的位置。
理想情况下,应将调用其他函数的函数写在被调用函数的上方。
反例:
正例:
注释
只对存在一定业务逻辑复杂性的代码进行注释
注释并不是必须的,好的代码是能够让人一目了然,不用过多无谓的注释。
反例:
正例:
不要在代码库中遗留被注释掉的代码
版本控制的存在是有原因的。让旧代码存在于你的 history 里吧。
反例:
正例:
不需要版本更新类型注释
记住,我们可以使用版本控制。废代码、被注释的代码及用注释记录代码中的版本更新说明都是没有必要的。
需要时可以使用 git log
获取历史版本。
反例:
正例:
避免位置标记
这些东西通常只能代码麻烦,采用适当的缩进就可以了。
反例:
正例:
避免在源文件中写入法律评论
将你的 LICENSE
文件置于源码目录树的根目录。
反例:
正例: