命名规范

名字的重要性不言而喻，在项目愈发复杂的今天，大量的变量和方法充斥在项目中，很多时候我们的时间浪费在识别乱七八糟的变量名上，尤其在重构和修改他人代码时，浪费了程序员宝贵的创造时间。

一个好的名字，应该要 看其形知其义：

1. 名副其实
   名副其实说起来很简单。我们想要强调，这事很严肃。选个好名字要花时间，但省下来的时间比花掉的多。注意命名，而且一旦发现有更好的名称，就替换旧的。这么做，读你代码的人（包括你自己）都会很开心。

2. 避免误导
   程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词。

3. 做有意义的区分
   如果程序员只为满足编译器或解释器的需要而写代码，就会制造麻烦。例如，因为统一作用范围内两样不同的东西不能重名，你可能会随手改掉其中一个名称，有时干脆一错误的拼写充数。

例如：

以数字系列命名

let list1;
let list2;

这样的命名存属误导，完全没有提供正确的信息，没有提供导向作者意图的线索。

废话区分

假设你有一个Product类，如果还有一个ProductData或者ProductInfo类，那他们的名称虽然不同，意义却无区别。Info和Data就像a、an、the一样，是意义含混的废话。

废话都是冗余。Variable一词永远不应当出现在变量名中，NameString比Name好吗？难道Name会是一个浮点数不成？如果是这样就触犯了关于误导的规则。

getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();

当这三个方法出现在一个类中，调用者知道该掉哪个？

如果缺少明确规定，变量moneyAccount与money没区别，customerInfo与customer没区别，accountData与account没区别，theMessage与message没区别。要区别名称，就要以读者能鉴别不同之处的方式来区别。

文件、目录名

• 命名方法：小写字母
• 命名规范：一律使用名词，单词以短横线做间隔。
• 命名建议：
  1. 目录、文件名不允许使用非字母开头
  2. 目录、文件名不允许使用动词类名称（一律使用名词）
  3. 目录名称不允许使用超过二个单词，文件名不允许超过三个单词

// 坏的命名
_login.js
1login.js
healthinform
getToken

// 好的命名
login.js
health-inform
token-utils

JS 命名

变量名

• 命名方法：LowerCamelCase（小驼峰命名法）
• 命名规范：{意义描述+可选类型描述}的组合，首字母小写
• 命名建议：如下

尽量在变量名字中体现所属类型，如:length、count等表示数字类型；而包含name、title表示为字符串类型。

let commentList;
let content;

尽量不要用缩写，除非这个缩写是公认的，如：library => lib。单词缩写附表：

icon          ic
color         col
divider       di
selector      sl
average       avg
background    bg
buffer        buf
control       ctrl
delete        del
document      doc
resource      res
error         err
escape        esc
increment     inc
infomation    info
initial       init
image         img
length        len
library       lib
message       msg
password      pwd
position      pos
server        srv
source        src
string        str
temp          tmp
window        win
...           ...

boolean值定义

检查某个属性是否为空或者某条记录是否存在的方法，通常命名为 hasXXX()，例如 hasJoined()。
检查对象状态的方法通常以 is+形容词 命名。例如 isClosed()，isReady()

常量名

• 命名方法：全部大写
• 命名规范：单词之间用下划线分开
• 命名建议：无

const PAGE_SIZE = 20;

方法名

• 命名方法：LowerCamelCase（小驼峰命名法）
• 命名规范： 方法名通常是动词或动词+名次。
• 命名建议：如下

资源命名

资源的字母名称必须全为小写，这是因为在某些对大小写字母敏感的操作系统中，当文件通过工具压缩混淆后，或者人为修改过后，大小写不同而导致引用文件不同的错误，很难被发现。

图片资源

• 命名方法：全部小写
• 命名规范： 采用{ 前缀 + 范围 }命名方式，用短横线区分
• 命名建议：如下

图标类，添加ic前缀
背景类，添加bg前缀

示例：

// 好的命名
ic-share.png
ic-avatar.png
bg-head.png

// 坏的命名
cheats-one.png
bg-2.png
new-1.png
accidentBanner.png

CSS 命名

遵守的原则

首先是命名要讲究简单而不失语义化，其次要时刻思考复用性，选择器的性能等。鉴于此，BEM 的命名规范逐渐风靡起来，BEM 是由Yandex团队提出的一种前端命名方法论。BEM 命名约定更加严格，而且包含更多的信息，同时避免了后代选择符带来的性能问题。

BEM 方法论

BEM的意思就是块（block）、元素（element）、修饰符（modifier），命名约定的模式如下：

.block{}
.block__element{}
.block--modifier{}

• .block 代表了更高级别的抽象或组件。
• .block__element 代表 .block 的后代，用于形成一个完整的.block的整体。
• .block--modifier 代表 .block 的不同状态或不同版本。

BEM 的关键是光凭名字就可以告诉其他开发者某个标记是用来干什么的。通过浏览HTML代码中的class属性，你就能够明白模块之间是如何关联的：有一些仅仅是组件，有一些则是这些组件的子孙或者是元素,还有一些是组件的其他形态或者是修饰符。我们用一个类比 / 模型来思考一下下面的这些元素是怎么关联的：

.person{}
.person__hand{}
.person--female{}
.person--female__hand{}
.person__hand--left{}

顶级块是‘person’，它拥有一些元素，如‘hand’。一个人也会有其他形态，比如女性，这种形态进而也会拥有它自己的元素。下面我们把他们写成‘常规’CSS:

.person{}
.hand{}
.female{}
.female-hand{}
.left-hand{} 

这些‘常规’CSS都是有意义的，但是它们之间却有些脱节。就拿.female来说，是指女性人类还是某种雌性的动物？还有.hand，是在说一只钟表的指针（译注：英文中hand有指针的意思）？还是一只正在玩纸牌的手？使用BEM我们可以获得更多的描述和更加清晰的结构，单单通过我们代码中的命名就能知道元素之间的关联。BEM真是强大。

参考连接

• BEM —— 源自Yandex的CSS 命名方法论
• 如何看待 CSS 中 BEM 的命名方式？ - 知乎
• BEM CSS命名规范二 Key concepts