引言
不要嫌弃函数名过长
变量 / 函数 命名头部
什么时候用 has ， 什么时候用 is
一个好的命名需要遵循的规则
函数变量
使用缩写
比较通用的缩写
常量命名
单词拼接 加深语义化
引入自定义组件
文件命名的风格
引言自己总结的一些常用的命名规范，好的命名不仅可以使代码看起来简洁，并且维护起来也方便了许多。作为初级程序员，不给他人增加负担也是需要学习的
不要嫌弃函数名过长const getLocationPermission = () => {}
这是一个用来获取定位权限的函数。虽然这个名称很长，但是语义化清晰，看一眼就知道他是用来做什么的。这里可以拆分成为 3 部分 get 获取的意思 location 定位的意思 permission 权限的意思， 这样一个十分具有语义化的函数命名就完成了。
变量 / 函数 命名头部一般为动词，后面加上具体要做什么的名词
| get | getUserInfo | 获取用户信息 |
| del/delete | delUserInfo | 删除用户信息 |
| update / add | updateUserInfo / addUserInfo | 修改用户信息 / 增加用户信息 |
| is | isTimeout | 是否超时 |
| has | hasUserInfo | 有没有用户信息 |
| handle | handleLogin | 处理登录 |
| calc | calcAverageSpeed | 计算平均速度 |
_ : 一般用于表示私有的字段，不希望外部访问
例如：_index
当然也有写在尾部的风格
例如：index_
什么时候用 has ， 什么时候用 ishas 常用于表示有没有或者是否包含 / 而 is 常用于表示是不是，是否
has的使用场景，例如
const hasLocationPermission = ?
// 有没有定位权限
const hasUserInfo = ?
// 有没有用户信息
...
is 的使用场景
const isShow = ?
// 是否（展示/显示)
const isTiemout = ?
// 是否超时
...
总结一下: has 是 "有没有" 包含的关系，而 is 则是 "是不是？"这个意思
一个好的命名需要遵循的规则首先，你要清楚知道你这个函数是用来干什么的。比如我需要写一个函数用来处理对象、数组等数据是否为空。那么我可以这样写 isEmpty 是否为空。例如我需要一个函数来获取本地保存的用户信息，另一个是需要通过网络请求来获取用户信息那么我可以这样来编写
const getLocalUserInfo = ?;
const getNetWorkUserInfo = ?;
仔细拆分，获取关键的字眼。 '获取本地保存的用户信息' => get（获取）local（本地）UserInfo（用户信息） 这样，一个十分具有语义化的函数命名就完成了
函数变量使用小驼峰命名规则 / 组件构造函数使用大驼峰 / 组件文件名使用下划线开头
小驼峰
const getUserInfo
大驼峰
const GetUserInfo
下划线
const _getUserInfo
使用缩写
注意点1： 通用性，不能随便拉出来一个单词就使用缩写，例如我想写一个 class 用于管理整个用户本地存储信息的获取、修改、删除等操作。可以这样命名这个class ：LocalUserInfoManage 或者说放到 同一个 localStroage 目录下，每一个再使用 UserInfoManage / UserConfigManage 等用于区分。 但是不能够 这样命名 lum ？
l （local）u （user / userInfo）m （manage）！！？
这样就比较迷惑了， 命名本来就是让其他人看起来更加简单易懂，而不是增加阅读负担
注意点2：保证统一性 既然某个单词使用了缩写， 那么最好都用缩写，不能有的写，有的不写
注意点3：缩写是作为一个单词存在，也就是这样的规则去命名的，例如： typeScript 缩写 ts这里第一个是小写，那么就是小写，后面的 Script 不再是单独的一个单词，应该是与前面是属于一个单词。转换规则 typeScript => tscript => ts , 同理如果 TypeScript => Ts ， 这是只在命名的情况下的转换
注意点4：不要通过删除单词中的字母来达到缩写的目的
一些不好的命名：
const n = ?// 无意义的命名
const nError = ?// 不明确的命名
const wgcComponents = ? // 不明确的命名，或者就你的团队能看懂，一旦有人员变动维护就会困难
const scid = ?// 不能用中文，也不能用中文缩写 sc （删除）
比较通用的缩写
| message | msg |
| information | info |
| button | btn |
| background | bg |
| response | res |
| request | req |
| image | img |
| utility | util |
| prroperty | prop |
| source | src |
| boolean | bool |
| error | err |
| settings | set |
以上有很多其实在平时已经有使用到，也还有很多没有写进去的，使用缩写命名的时候一定要注意规范，参考第六点。
常量命名关于常量的命名，一般不会改变的变量，这类变量比较固定（例如：一天有多少毫秒，180deg 或者 xxx deg的选择角度，再就是和其他人约定好的魔鬼数字等等）他们的共同点是我们无法使其变化，也可以说我们不希望他会被改变。
这种常量的话一般是使用全大写，每一个单词使用 _ 下划线分开。 例如
一天毫秒数综合
const DAY_MILLI_SECOND_SUM = ?
单词拼接 加深语义化
by： 通过
const aid = getUserAid()
这段是获取用户 aid ， 使用 get user aid， 无可厚非，但有时候我们并不需要去从用户信息中拿，而是直接从本地拿。
此时就可以加上 by 了， 并且语义表现上也会丰富
const aid = getAidByLocal(); // 通过本地获取 Aid
const aid = getAidByUserInfo(); // 通过用户信息获取 Aid
参考命名：
document.getElementById
document.getElementByClassName
...
引入自定义组件
现在你有一个组件 picker ，基于 picker 封装了一个时间选择器目录结构如下
---conponents
--- picker
--- index.jsx
--- date.jsx
那么引入的命名应该是 父级文件名 + 组件名 / 或者你直接把组件的文件名命名成这样也可以的
import pickerDate from 'component/picker/date.jsx';
文件命名的风格
_ 或者 - 分割单词时，一定要统一，二者选一个就可以
--- conponents
--- test-file1
--- test_file2
以上就是前端命名规则总结的详细内容，更多关于前端命名规则的资料请关注易知道(ezd.cc)其它相关文章！
