在老代码及现在新开发的小程序项目中，有大量命名不规范的现象，命名不规范会严重影响代码的维护性，导致不必要的报错的bug，最主要是会影响后续人员的开发的心情，让后续开发人员对代码绝望，继而产生破窗效应。
常见不规范命名
拼写错误
batch写成btach/branch，拼写错误容易引起歧义，以后维护代码的人会一脸懵逼。并且容易造成引用报错，例如批量删除一开始命名是拼写错误命名成btachDelete，后面使用的人会直接通过batchDelete调用该方法，就会引起报错。
中英文混用
中英文混用已经很过分了，中文部分还要缩写就是翔中之翔。例如促销模块中经常有CxSheet这种用cx开头的命名。cx啥意思？出现？船新？传销？查询？
中式英语
这里指把用中式英语的方式把汉字挨个翻译成英文单词。举个例子，扫码->sweepHorse，sweep 扫，horse 🐎。
不必要的简写
例如促销全拼是promotion，缩写成pro之后就很有歧义，首先pro本身有加强版的意思，其次productio/problem/provide 都是pro开头，容易误解。不要吝惜你的键盘了，拜托多打几个字。
正反义词错用
例如：showDialog/closeDialog，show和hide是一对，open和close是一对。
1-9 或者 a-z 命名
像是有些按钮命名成 btn1、btn2、btn3，只是在写代码的时候一时爽了，后续从这些命名中读取不到任何信息，会非常的痛苦必须进入每个方法中去看才能了解到这个按钮的用途。
单复数不分
良好的单复数命名可以帮我们了解到该数值的类型（特别是我们现在项目中没有用到ts的情况下）。例如 items一看就知道是数组，里面包含item，item则是单个商品信息。
命名规范
命名格式
| 命名对象 | 命名格式 |
|---|---|
| 图片 | 小写字母，用'-'或者'_'连接。不是通用的图片，就建议根据类别-模块-功能的格式。例如：icon_itemlist_618banner |
| css | '-'连接 |
| html/js/css文件 | 小驼峰 |
| js类/组件 | 大驼峰 |
| 常量 | 大写命名 |
| 私有变量 | '_'下划线命名 |
变量命名
函数命名
命名格式：小驼峰（构造函数采用大驼峰）
命名规则
- 调用api类型函数：可以用api本身的名字命名。
- 常规函数：如下。
常规函数命名
- 使用小驼峰格式
- 一般以动词开头：
| 操作 | 命名 | 举例 |
|---|---|---|
| 判断是否可执行 | can | canUserVipFunction |
| 判断是否含有某值 | has | hasActivity |
| 判断是否为某值 | is | isVip |
| 获取某个值 | get | getUserInfo |
| 设置某个值 | set | setUserInfo |
| 处理操作 | handle | handleCancel |
其他像打开弹窗、关闭弹窗openDialog/closeDialog也是直接用动词签名命名。
- 命名具有语义化，按照职责命名。如一个搜索的点击事件不能用
onClick应该用onSearch。
常量命名
采用大写字符+'_'的方式
// 配置页数
const PAGE_NO=1;
// 配置pagesize
const PAGE_SIZE=20;
私有变量
采用前缀'_'+变量名的方式
let _this = this;
命名网站推荐
在这里推荐一个网站，codelf ，点击去搜索就能获取到对应的命名。
webstorm也有配合codeif命名的插件，使用教程点这里。
题外话
好了，命名规范就到此结束了，从知乎上找来几个小笑话开心一下。
前端有一段代码是20多个按钮，根据不同的状态，展示不同的按钮组合。。。然后每个按钮是一个变量表示其显示还是隐藏，。。。
然后就看到了，
show1,show2,show3.......show22
你以为这是全部嘛。错。其中一个show17
它尽然叫做shoe17。。。。我。。。。。
del_yeye（）
翻过去看看定义是啥
parent().parent().remove()
emmm
原来是要把爷爷删除掉(ﾉﾟ0ﾟ)ﾉ~
上面案例源自知乎 作为程序员，有没有让你感到既无语又崩溃的程序命名？
网友评论