对于变量命名，之前做开发的时候不太注意，觉得只是起个名字这么简单而已。但命名的时候也会纠结很多问题，不知道该用什么单词，往数据库添加数据的时候用create还是add，对话框使用model还是用dialog，有时候甚至不知道怎么起名字。
首先列举几个不规范的命名
1. 随意使用简写
<div class="search-form form-inline edit-form x-ac-he"> <!-- x-ac-he是什么样的类名 -->
...
</div>
data = {
mulSel:[], // mul表示多个，sel一眼看上去不知道是啥
chooseCate:0, // Cate 不知道是啥
total:0 // 知道total表示总共，可能是统计数据长度，但具体表示什么长度不知道
}
<ask-remove :callback="fetchData" :url="orgApi.delete"> <!-- ask-remove 询问删除？表示删除确认对话框，用delete-confirmation, fetchData，获取数据？ -->
<strong v-text="selected.cOrg_Name"></strong>
</ask-remove>
2. 变量名称意思不明确，容易误解
用total表示总数，单具体表示什么总数，要翻遍代码找找total具体指向。fetchData，不知道获取什么数据集。orgs()，如果不是后面带个括号都不知道是要干嘛。showButton返回true/false
3. 不明确的状态标示
scope.row.parent != 0， scope.row.authorityType == 1 不知道0，1具体代表的是什么，也没有注释。就算有注释，也不容易记住
4. 错误的命名方法
用selected表示选中的对象集，用showDialog表示弹出框的状态，常量用小驼峰命名
以上是以往项目里犯过错误的地方，因为之前都是一个人写代码比较多，偶尔碰到修改别人代码的时候会发现改起来很费劲。不敢动。另外很少对之前的项目做维护，一般都是一次性的。
命名规范的好处：
可读性高，不用看注释就能知道一个变量，方法是用来干嘛的，对整个代码，业务理解起来比较容易
提升开发效率，便于共享和协同开发，不需要一个一个去问别人写的是什么
降低维护成本，读起来都很费劲的代码，维护起来自然不易
具体做法
1，单词拼写要正确
这是最低级的错误，如果单词都不能拼写正确，时间长了自己可能会遗忘，更容易造成语法的上错误。别人可能都不知道你写的什么，有时候还要去靠猜。 这是最让人头疼的
2，使用简介明确含义的英文单词，词组
不使用汉语拼音，中英混写
尽量使用业务上便于理解的单词，很多时候项目小组的沟通不是区分变量，函数，类，接口这些技术上的沟通，更多的是业务上，数据上的沟通。使用users/userlist，比使用useArr更能表示一组用户集
避免不明所以的简写，可以使用简写，但要用大家共识的那些简写。org - organization, btn - button, str - string。最好不使用简写，这样代码更容易阅读。
3，正确选择不同类型命名的方式
变量，属性命名使用名词，名词词组或形容词+名词组合。
数组，统一使用名词的复数形式，或者名词+list，最好只用一种方式
对象，使用单数形式的名词+Info，或单数名词。见过有人用名词+Repository
状态，一般值为布尔类型，使用形容词表示状态。selected 是否选中，loading 正在加载。可以在形容词前加is/if/has
方法，使用动词+名词、名词词组。getUsers, getSelectedOrg
限定命名，表示名词的最大，最小，总数等，用名词+限定词，把重要的名词放前面；如userTotal, userAccount, stringLength
4， 约定好常用的命名单词，词组
CSS 固定命名规则，BEM命名规则
5， 命名方法
变量，方法使用小驼峰(lowerCamelCase)命名
局部变量，方法使用方法名后加下划线 this.addUser_, this.user_
类名，组件，接口引用使用大驼峰（UpperCamelCase）命名
枚举，常量使用大驼峰（UpperCamelCase），并且单词之间用下划线（_）分割
参数使用小驼峰(lowerCamelCase)命名，如果参数是第三方类库，可以在参数名前加类库的标示符。如引用jquery
最后：想要提高代码质量，还是要经常去看下开源代码，欣赏学习别人是如何约定命名规则和编写代码的。另外做为程序员要时刻保持一份review 自己代码的心，不断的重构和修改精进自己的代码。
附上 google 的代码规范，不限于命名规范