逆袭女神成功之代码命名

case1：

狗蛋想看女神的详细个人信息，他调出了官网的代码：

// list即可能是列表也有可能是表格 const configListData； const configList； const configData； const configFormList； ......

WTF!这些变量名根本一模一样好吗？我到底该看哪个？

解析：

让我们来看一下elementui的命名:

• 表格: table 复制代码
• 表单：form 复制代码
• 列表：list 复制代码

采用机翻往往会出现同名非同义的情况，需要对基础组件置顶一个自己的规范，设想一下，如果多人维护统一套代码，每个人风格不统一又没有注释，很容易出现神秘变量。

1. 造轮子尽量让名字单一，并用统一的命名规则去封装组件，例如: { data:'', //数据 config:'', //配置 size:'', //尺寸 style:'', //样式 state:'', //状态 show:'', //展示 ...... } 复制代码
2. 尽量避免语义相近的变量，因现在大都使用ui框架的情况，如果页面中出现俩种相同类型的组件建议使用这种方式取名： studentTable， // 内容-组件模块 （如果有很多学生的表格，最好说明是什么学生） 复制代码

狗蛋好不容易理好了表格，打算用烂熟于心的女神三围做查询条件，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(); } ......

写了个大概，根据具体业务还能优化，重构后的好处是：

1. 每个计算公式都有它自己的函数和明确的名字
2. 大致流程不会变，每个函数的内部可以根据需求变化计算方式
3. 输出价格的函数是不变的，之后我们不需要关心他是怎么实现的

参数名

完全是个人风格了：

1. 参数不宜过多，超过3个就需要考虑可以组合成对象的形式参考(变量case2)
2. 参数统一，如果是同一流程中的传参，建议用同一参数名方便快捷搜索快速定位(ctrl f)， 如下代码可以通过movieName快速定位相关处理流程 const movie = []; function updateDesignation(){ const movieName = 'SSNI-436'; downLoadMovie(movieName); } .... 此处省略一万行代码，但是我们可以通过movieName快速定位参数走向 .... function downLoadMovie(movieName){ movie.push(movieName); } 复制代码

女神低下头在狗蛋的耳边轻声说道，其实你不用为我复出那么多，我就喜欢你写代码的样子，真的好帅。（我就喜欢你人傻钱多）

狗蛋：嘿嘿，女神原来对代码感兴趣，你认为什么语言是世界上最好的语言？

女神：。。。。。。

更多信息欢迎关注！