俗话说得好，万事开头难。而对于前端 coder 来说，每次新项目、新需求来的时候，我想大家最苦恼的往往就是如何去命名，无论是项目名称、页面的文件名称亦或是代码中的方法名称，对于我来说，但凡名字想好了以后，我觉得需求就已经写完一半了。
如何才能更好，更优雅的去解决这些命名问题呢？在这之前，先随我看一些不合适的命名示例吧。
不合适的命名
我们先来看一些例子：
无意义的，抽象的，任何地方可以使用，谁都不知道你这里用的命名来源是谁
// bad
const data;
const info;
const tool;
简称，单词的简称或者缩写很容易让人无法确定具体指代什么
// bad
const comp;
const crt_date;
// good
const components;
const company;
const current_date;
数字或者字母结尾的命名，让其他人无法获取这些之间的区别
// bad
const button1;
const button2;
const info1;
// good
const importButton;
const userInfo;
全局的地方不要用前置或后置下划线，前置下划线通常代表了私有变量
// bad
const _firstName_ = 'Zcy';
const firstName_ = 'Zcy';
const _firstName = 'Zcy';
// good
const firstName = 'Zcy'
命名规则
如何让命名更简单呢，只要遵循一些规则规范，总能将复杂的事情拆分开来，变成一件简单的事情。
直白、有意义
想要让你的命名简单易懂，最简单的方式就是直白并且有意义，直接了当的在命名中体现出你这个命名的功能，或者描述，举个例子：
// bad
function getInfo(){};
function formatList(){};
const data = [];
// good
function getUserInfo(){};
function formatNewsList(){};
const articleData = [];
如果在页面中定义了上面这样的变量，哪种写法可以让你在没有注释的情况下，就能快速了解原作者的书写意图呢？（当然，代码中还是需要一些必要注释的） 。
所以在命名的时候，需要的就是直白、完备、有意义，让别人通过命名就能了解到这个名称（无论是变量、方法或者是样式名）背后的的含义，这样的命名就是高效的、易懂的。
遵从惯例、标准
习惯使用业界习惯的命名标识，或者是约定俗成的书写习惯。
用 id 当做数据标识命名，而不是 identifier
例如布尔值命名类型，通常只有两个值类型：真，假，根据不同的使用场景，也可以有一些常用的命名方式
// 可见、状态等，可用 is+动词/形容词的方式
const isVisible;
const isLoading;
// 配置，选项等类型，可以用 withXxx、hasXxx 来标识是否有某个属性等,enableXxx 来表示是否开启配置
const withTab;
const hasPlan;
const enableFilter;
例如方法命名，也可以使用动词 + 名次类的组合命名方式，操作类方法 fetchXxx，getXxx，当需要根据某些属性获取数据时可用 ，getXxxByYxx 这类的命名，删除类方法 deleteXxx，格式化数据 formatXxx
// 数据获取方法
function getUserInfo(){};
function fetchSearchList(){};
// 需要根据一些属性去获取数据
function getGoodsById(){};
function queryUserByName(){};
// 删除数据
function deleteUser(){};
function removeGoodsItem(){};
// 格式化数据
function formatDate(){}；
function sortByDesc(){}
规范约束
团队如果用统一的命名规范，那就一定要遵守，例如文件名的命名是大写字母开头的驼峰写法，那你的命名就不能再修改为其他方式，在规范创建之初或者修订时可以提出修改意见并进行讨论，但如果已经确立的，就不要再。去自由的破坏规范。
当然也可以使用一些辅助手段帮助约束代码中的命名校验，**例如在 Eslint 配置中加入 id-match 或者 camelcase，前者可以直接通过正则配置自己需要的命名规范，后者则是直接采用了驼峰命名的规范约束 **。
网友评论