大家好，我是张三岁🤣，一只法系前端⚖️。爱分享🖋️、爱冰冰🧊🧊。
欢迎小伙伴们加我微信：maomaoibingbing，拉你进群，一起讨论，期待与大家共同成长🥂。
前言
优秀的代码往往是最通俗易懂的代码，在于它的易于维护。在开发过程中，变量/方法优秀的命名往往有助于理解该变量/方法的用途，起到命名即注释的作用。而糟糕的命名往往会让人摸不着头脑。为了提高代码的可维护性，我们需要更优雅的命名方式。
一、通用规则
1. 有意义
起一个有意义的变量名这条相信绝大多数开发者都能做到，即变量名有实际的指代意义，在此不再赘述。
2. 指代具体
命名时需要使其更加具体详尽，可以具体到所在的模块，或者能表达出其逻辑/功能。
/* bad */
.title {}
/* good */
.head-title {}
// bad
const info;
// good
const userInfo;
3. 遵循传统
无论是CSS、JavaScript、还是文件的命名，都有一些约定俗成的惯例和规范，我们只需遵循即可。
4. 约定规范
命名的规则有很多种，没有高低之分，只有相对合适，没有绝对完美的规则。通常为了维持项目的风格统一，通常在一个项目中，相同种类的规则只选取一种。毕竟规范也只是一种工具，运用规范的根本目的是为了更好的开发和维护，太过复杂的规范反而会阻碍正常开发。因之，在项目启动前，在技术栈选取后就应当进行规范的约定，这个过程是团队意见的整合，毕竟规范是要靠团队成员的相互配合。
二、CSS 中的命名
1. 划分原则
CSS中的类名根据其职责可以分为公共类名和自定义类名。其中公共类名又可以分为常见类名（一般是约定俗成）和工具类名。
2. 常见类名
下面整理了一些常见的 css类名 供大家参考：
| CSS类名 | 说明 |
|---|---|
| 布局 | |
| layout | 布局容器 |
| wrapper/wrap | 控制布局宽度的外围容器 |
| header/head/hd | 头部/顶部 |
| main/bd | 主体部分 |
| footer/foot/ft | 底部 |
| sidebar | 侧边栏 |
| 容器 | |
| banner | 广告栏 |
| content | 内容部分 |
| copyright | 版权 |
| list | 列表 |
| menu/submenu | 菜单/二级菜单 |
| nav/subnav | 导航栏/二级导航 |
| 组件/细节 | |
| arrow | 箭头 |
| btn | 按钮 |
| download | 下载 |
| logo | 徽标 |
| message/msg | 信息 |
| news | 新闻 |
| product | 产品 |
| search | 搜索 |
| status | 状态 |
| summary | 摘要 |
| tab | 标签页 |
| tag | 标签 |
| text/txt | 文本 |
| tip | 提示 |
| title/subtitle | 标题/二级标题 |
| 尺寸 | |
| large | 大 |
| middle | 中等 |
| small | 小 |
| mini | 迷你 |
| 位置 | |
| top/right/bottom/left | 上/右/下/左 |
| 关系 | |
| first | 第一个 |
| last | 最后一个 |
| prev | 上一个 |
| current | 当前项 |
| next | 下一个 |
| forward | 向前 |
| back | 向后 |
| 状态 | |
| primary | 主要 |
| info | 提示信息 |
| success | 成功 |
| warning | 一般警告 |
| danger/error | 严重警告/错误警告 |
| link | 文字链接 |
| plain/ghost | 按钮是否镂空 |
| light | 亮模式 |
| dark | 暗模式 |
| disabled | 禁用 |
| active | 激活 |
| checked | 选中 |
| loading | 加载中 |
3. 自定义类名
自定义类名一般以短横线“-”或者下划线“_”中的一种作为单词间分割，通常不使用驼峰命名，以此区别于变量。在项目中通常使用 scss、less 来进行样式书写，大大降低了类名重复引发的样式问题。因此我们只需要关注一个模块的外层容器类名。通常采用 模块名称-修饰名称 的命名方式。
三、JavaScript 中的命名
1. 命名规则
1.1 小驼峰式命名(lower camel case)
第一个单词以小写字母开始，第二个单词的首字母大写。例如：firstName、lastName。一般的变量、函数均采用小驼峰式命名。
1.2 大驼峰式命名(upper camel case)
每一个单词的首字母都采用大写字母，例如：FirstName、LastName，也被称为 Pascal 命名法。一般类采用大驼峰式命名。
1.3 全大写式命名
常量通常采用全大写式命名，单词间以下划线“_”分割。
1.4 以下划线开头式命名
一般情况下，局部变量或者私有变量采用下划线开头，后跟驼峰式命名。
2. 命名单词选择
一般情况下，变量/函数的命名采用动词前缀+名词修饰。
| 前缀 | 说明 |
|---|---|
| 变量 | |
| can | 是否可以执行某操作 |
| is | 是否xxx |
| has | 是否有xxx |
| 函数 | |
| calc | 计算 |
| change | 改变 |
| fetch/get | 获取（数据) |
| handle | 操作 |
| judge | 判断 |
| set | 设置 |
小结
任何的 代码规范 都是利于我们 开发 和 维护 的，它存在的意义就是让我们的代码可读性更高/协作更方便的。对于多种不同的 规范 ，没有绝对意义上的谁好谁坏，只有适合与不适合。 代码规范 本身是为(协作)开发提供便利的，要避免本末倒置，还是要将更多的精力投入到项目的核心业务逻辑而非代码规范的条条框框的束缚，因为任何规范的代码都不是一朝一夕能运用自如的，要持之以恒才能力透纸背。循序渐进的在优化代码的漫漫长路上上下求索！