背景
计算机科学存在两个难题：缓存失效和命名。命名对于程序员来说是就是一个难题，有时候因为命名，可能会引起别人的误导，疑惑等，对开发效率，项目的质量影响可大可小。
Js 命名
JavaScript 的命名应遵循简化、语义化的原则。
变量
命名方法: 小驼峰式命名法（lowerCamelCase） 命名规范：前缀为名称/形容词 （函数前缀为动词, 以此来区分函数和变量）
// 好的命名方式
let maxCount = 10;
let tableTitle = '啦啦啦';
// 不好的命名方式
let setConut = 10;
let getTitle = '啦啦啦';
常量
命名方法：名词全部大写 命名规范：使用大写字母和下划线来组合命名，下划线用来分割单词。
const MAX_COUNT = 10;
const URL = '//www.huifenqi.com';
函数/方法命名
命名方式：小驼峰式命名法（lowerCamelCase） 命名规范：前缀应该为动词 命名建议：常用动词约定如下。
| 动词 | 含义 |
|---|---|
| can | 判断是否可执行某个动作 |
| has | 判断是否包含某个值 |
| is | 判断是否为某个值 |
| get | 获取某个值 |
| set | 设置某个值 |
| load | 加载某些数据 |
eg:
// 是否可阅读
function canRead() {}
// 获取名称
function getName() {}
类/构造函数
命名方法：大驼峰式命名法（UpperCamelCase），首字母大写。 命名规范：前缀为名称。
class Persion {
constructor(name) {
// ...
}
}
let person = new Person('CXL');
类的成员
公共属性和方法：跟变量和函数命名一样。 私有属性和方法：前缀为下划线_, 后面跟公共属性和方法一样的命名方式。
class Person {
// 私有属性
_name: string;
constructor() { }
// 公共方法
getName() {
return this._name;
}
// 公共方法
setName(name) {
this._name = name;
}
}
图片命名
如果是通用性质的图片，例如LOGO，菜单，侧边栏，背景等，就直接使用小写字母命名。比如：logo.jpg ，menu.jpg，aside.jpg，bg.jpg。
如果不是通用的图片，就建议根据类别-模块-功能的格式。使用小写字母，‘-’或者‘_’分割，如下例子：
| 图片名称 | 意义 |
|---|---|
| btn-submit-comment.jpg | 提交评论的按钮 |
| bg-product-list.jpg | 产品列表模块的背景 |
| icon-views.png | 浏览数的图标 |
| icon-btn-vote.png | 投票按钮 |
| ad-news-aside.jpg | 在新闻侧边栏的广告图片 |
Vue 命名规范
命名建议：
1. 事件处理应以handle开头,如handleBlur;私有事件名前加下划线，其它方法同上述函数命名。
2. 在插件、混入等扩展中始终为自定义的私有属性使用$_ 前缀。并附带一个命名空间以回避和其它作者的冲突 (比如 $_yourPluginName_)。
这是因为Vue 使用 _ 前缀来定义其自身的私有属性，所以使用相同的前缀 (比如 _update) 有覆写实例属性的风险。即便你检查确认 Vue 当前版本没有用到这个属性名，也不能保证和将来的版本没有冲突。
3. 单文件组件的文件名应该要么始终是单词大写开头 (PascalCase)。
4. 和父组件紧密耦合的子组件应该以父组件名作为前缀命名。
组件不超过200行
经常看到某个项目中组件一打开，1000+行，维护性、可继承性都很差，打开之后一脸懵逼。大多数情况下（非业务需要）超过200行的组件都可以拆分成更小的组件来维护。当你把所有组件都拆完了，你会拆出很多纯组件-不掺杂业务的组件，这是就可以进行公共组件抽象提取，你会发现有很多可以提取的公共组件。
git命名
需求（版本）开发
1.对于基础模块稳定的项目，从master上拉取dev分支（公共分支），再拉取功能分支。
2.对于从0到1的项目，从master上只拉取公共分支，在同一个分支上开发，相互依赖紧密，减少合并时的解决冲突的沟通成本。
eg: 现在移动端项目
app-6.6.0 包含app
web-6.6.0 纯web
上线准备
1.拉取最新的master到本地，反向合并到公共分支，在本地解决冲突。
2.提交公共分支，在远程操作合并到master。
3.打包，构建发布预发环境。
4.上线一段时间稳定后，拉取master,本地生成changelog,提交到仓库，打tag
线上问题处理
1.从master上拉取bugfix分支
eg：
hotfix-news-20190912 关键词-业务-日期
2.后续操作同上，merge时把jira的问题版本号带上。
错误的命名
以1-9，a-z命名
这个情况相信大家都会遇到过，比如页面上有几个按钮，有人命名成 btn1，btn2，btn3，btn4...。或者 btnA，btnB，btnC，btnD。这样的命名看似简单，但实际上从这些命名里面读取不到任何信息，以后会可能会痛苦些。
混用命名格式
这个可以说还可以，但是看着就别扭，比如表示评论列表，有地方这样命名：comments，另一个地方这样命名： comment-list，还有这样命名： commentList。几种规范混在一起，就感觉不规范了。
单复数不分
这个情况不算恶劣，只算是一种规范吧，之前有分别有两个操作函数，一个是下载全部订单数据，一个是下载当前订单数据。但是两个函数的命名，一个是downloadOrderData，另一个是downloadOrder。这样也产生了一点懵逼感。 面对这样的情况，建议还是区分下单复数，downloadOrder，downloadOrderAll/downloadOrderList。区分了单复数的命名，如果有返回值，也可以让别人大概知道，单数可能就是返回单个记录，复数可能返回一个数组。
最后
关于命名的规范，每个公司都有自己的编码规范，只是很少公司能认真贯彻执行自己的规范，从而导致命名错乱。所以命名的难点，并不是命名本身有难度，难度在于在项目上，面对各种需要命名的对象，坚持使用一套命名格式，正确的命每一个名。
