鲁迅曾经说过: 所有代码都不是一次性的，无论是变更还是阅读，一语中的的名字便是好的设计。
正文
李狗蛋为了和自己心仪的女神在一起，使上了浑身解数，让我们看看他是如何逆袭的。
故事如有雷同纯属巧合，以下命名方式只是参考，没有真正的标准
变量名
case1：
狗蛋想看女神的详细个人信息，他调出了官网的代码：
// list即可能是列表也有可能是表格
const configListData；
const configList；
const configData；
const configFormList；
......
WTF!这些变量名根本一模一样好吗？我到底该看哪个？
解析：
让我们来看一下elementui的命名:
-
表格: table -
表单：form -
列表：list
采用机翻往往会出现同名非同义的情况，需要对基础组件置顶一个自己的规范，设想一下，如果多人维护统一套代码，每个人风格不统一又没有注释，很容易出现神秘变量。
- 造轮子尽量让名字单一，并用统一的命名规则去封装组件，例如:
{
data:'', //数据
config:'', //配置
size:'', //尺寸
style:'', //样式
state:'', //状态
show:'', //展示
......
}
-
尽量避免语义相近的变量，因现在大都使用ui框架的情况，如果页面中出现俩种相同类型的组件建议使用这种方式取名：
studentTable， // 内容-组件模块 （如果有很多学生的表格，最好说明是什么学生）
case2：
狗蛋好不容易理好了表格，打算用烂熟于心的女神三围做查询条件，OMG！这查询条件也太多了吧：
//vue中的data
这里用了苍老师的.....
{
age:'18',
sex:'female',
major:'english', //专业
class:'201',
bust:'90', //胸围
waistline:'58', //腰围
hips:'83', //臀围
table:'',
}
table.search({waistline,hips,bust});
报错：正经学校怎么可能会有三围啊！
解析：
表格的查询条件有很多，然而上面这一块并不全是学生表格中的查询条件。
狗蛋一怒之下修改了结构:
{
// 查询学生条件
studentSearchData：{
age:'18',
sex:'female',
major:'english', //专业
class:'201',
}，
// 查询私人条件
privateSearchData: {
bust:'90', //胸围
waistline:'58', //腰围
hips:'83', //臀围
}，
table:'',
}
table.search(studentSearchData); //少写几个变量
这样通过业务领域来抽象成个对象（类）来区分业务，在复杂的业务场景里不仅可以确认数据的职责链，通过命名让代码显得更加'模块化'，甚至在一些功能里可以更加便利的调用。
函数名
case1：
狗蛋为了维护女神的形象（占为己有）想把隐私条件修改（保存）了：
changeSearchData('privateSearchData');
updateSearchData('privateSearchData');
所以是哪个是修改函数?
解析：
建议采用 操作(restful)+内容 / 内容+行为 来命名
searchData(); //获取 加get多此一举，个人风格你们也可以加
initSearchData(); //删除
addSearchData(); //添加
updateSearchData(); //更新
removeSearchData(); //移除某个属性
deleteSearchData(); //删除
searchDataToString()； //转换数据格式
.....
case2：
帮女神清空购物车，计算她双11购物车的消费金额:
（数量 * 单价）* 折扣 + 距离 * 运费
function Price（）{
return (order.quantity * order.itemPrice) * order.discount
+ distance * shipping
}
狗蛋想修改购物车的计算逻辑但是无从下手
我们的项目里往往会出现这种代码，这并不是什么错误的代码（需求紧、懒癌），但是我们一定要重构它。这个函数中的代码过于复杂，以至于用一个名字无法解释它的具体行为
解析：
用单一职责重构它:
// 基本价格 = 数量 * 单价
function basePrice (){
return order.quantity * order.itemPrice;
}
// 折后价格 = 基本价格 * 折扣
function discountPrice (basePrice){
return basePrice * order.discount;
}
// 运费价格 = 公里数 * 运费
function shippingtPrice (){
return distance * shipping;
}
function Price（）{
return discountPrice(basePrice()) + shippingtPrice();
}
......
写了个大概，根据具体业务还能优化，重构后的好处是：
- 每个计算公式都有它自己的函数和明确的名字
- 大致流程不会变，每个函数的内部可以根据需求变化计算方式
- 输出价格的函数是不变的，之后我们不需要关心他是怎么实现的
参数名
完全是个人风格了：
- 参数不宜过多，超过3个就需要考虑可以组合成对象的形式参考(变量case2)
- 参数统一，如果是同一流程中的传参，建议用同一参数名方便快捷搜索快速定位(ctrl+f)， 如下代码可以通过movieName快速定位相关处理流程
const movie = [];
function updateDesignation(){
const movieName = 'SSNI-436';
downLoadMovie(movieName);
}
....
此处省略一万行代码，但是我们可以通过movieName快速定位参数走向
....
function downLoadMovie(movieName){
movie.push(movieName);
}
女神低下头在狗蛋的耳边轻声说道，其实你不用为我复出那么多，我就喜欢你写代码的样子，真的好帅。（我就喜欢你人傻钱多）
狗蛋：嘿嘿，女神原来对代码感兴趣，你认为什么语言是世界上最好的语言？
女神：。。。。。。
请不要再把代码写成推理小说，不是每个人都是侦探
如果觉得不错，请素质四连，点赞、关注、转发、评论，毕竟要恰饭的嘛
了解更多，关注技术公众号：ihap 技术黑洞 ！！！
