JS代码规范
质量意识
一些错误但大行其道的观点
- 我们没有时间写单元测试
- 应该给每一行代码加注释
- 代码中间的空格,括号非常重要
- 等我们有时间了再重构
- 只要坑挖得足够多,就可以筑起护城河(公司就离不开我了:))
- 测试时测试人员的事情,跟开发人员没关系
错在哪
- 没时间写测试,有时间改bug
- 正确的写注释,注释why而不是注释how
- 空格、括号远没有那么重要
- 重构是要每天进行的
- 只要坑挖得足够深,你的头发就会掉得更快
- 你应该能独立保证自己的代码质量,不要完全依赖测试人员
现状
人员水平
- 大部分程序员对质量的提升方法是堆时间(加班)
- 正确的办法是自动化、监控、预警
- 大部分前端对代码质量还停留在lint工具
- 正确的做法是静态分析(不运行代码进行分析)、单元测试(运行代码进行分析)、不断重构
我们要做的
- 不要被错误的观点同化
- 相信「一切能用机器做的事情,都应该交给机器来做」
- 一旦有时间自动化、测试的可能,就勇敢的上
语言特性
原则:我们应该优先使用能完成特定功能、无歧义、无副作用的特性
不要用的JS特性
绝对不要用
- 全局变量
- var声明
- ==运算符
- 包装类型String/Boolean
有些人不用
- class/new/this
- 比如React Hooks那帮人
用的人不多,尽量少用
- symbol、generator、iterator
- 反射
推荐使用的JS特性
一定要用
- === 全等
- ... 三个点运算符
- 模块 import export
- let const
- 析构赋值
- Promise / await
可以使用
- class
- getter/setter
- WeakMap
- Proxy
存在问题但可用
- 箭头函数
- 数组API
命名
坏命名示例:
// 小亮? 销量?
let xiaoliang
// 数组应该对于复数形式
let user = [{name: 'xxx'}, {name: 'yyy'}]
// 谁的flag?flag表达的含义过于抽象
let flag = true
// 没必要加info,似乎所有变量后都可以加info。太没必要了
let userInfo = {name: 'xxx'}
// handler 处理啥?
let handler = (x) => console.log(x)
// cnt container 还是 content ?没必要为了少写几个字母而引发歧义
let cnt = document.querySelector('#test')
// idx => index
let idx = 0
// cur => current
let cur = 0
首要规则
-
命名应该能让人秒懂
-
命名应该符合英语习惯
- 普通变量用名词
- 复数要加s或者对应复数形式
- 布尔用isXXX或hasXXX或形容词
- 禁止用showDialog表示是否展示dialog
- 普通函数用动词开头
- 钩子函数用介词加动词开头
- 容易混淆的对象加前缀,如$div
-
命名不准用缩写
- 如:cnt/idx/cur/prev/anal
- 某些特定的缩写可以用,比如for循环里的i,j,k
- 行业通用缩写当做一个单词,如html
注释
注释分类
-
对代码进行翻译的注释(垃圾注释)
-
对代码进行总结的注释(可能有过时的风险,最好能看到函数名就能知道这串代码在干嘛)
-
对bug进行分析的注释(非常好的)
-
对参考来源的注释(非常好的)
-
对潜在问题的警告的注释(非常好的,比如:千年虫)
-
发泄情绪的注释(最垃圾的注释,职业素养问题)
lint(毛边)
lint工具
- eslint
- Standard JS
- 不推荐jslint/jscs/jshint
建议
- 不要那么在意空格、括号
- 请关注命名、代码解构和单元测试
网友评论