不要使用匿名函数

作为函数式编程语言，函数在Javascript中的重要地位和巨大作用你尽可想象。但在其提供巨大便利的同时，也不可避免的带来巨大的问题。

匿名函数则更是一把双刃剑，它让函数式编程语言更加完美，也让代码更加难于阅读。你应该知道匿名函数是以牺牲语义化为巨大代价的。

如果一个函数没有名字，它可能无关紧要，在大部分场景中它都将失去意义。函数的名字跟你的名字，你朋友的名字，你家小宠物的名字一样，是重要关键的，否则你写它干嘛。

即使在看起来最没有必要的位置使用命名函数也有巨大价值

你可能随手就能枚举很多场景来证明匿名函数的便利性，不可否认有些场景无疑是有一些道理的，但大多数人以此为起点，以善小而不为。比如

Array.some,  Array.forEach,  String.replace

这样的例子能举出不少，我们也可以理直气壮的说他们不需要使用命名函数，使用匿名函数更方便，并且大家都是这么做的。但是别忘了，some，forEach，replace本身已经具有宽泛的语义了。但仍然可以更近一步：

1.Array.some, 广泛的语义是找出数组中是否有一些，但究竟有一些什么呢？

2.Array.forEach, 广泛的语义是遍历，Array提供无数的函数用于遍历，你为什么选择forEach, 而不是map，every等等？

3.String.replace, 广泛的语义是替换，但究竟是将什么替换成什么呢？

代码是写给人看的，

1.能不能不要让我去读你的代码猜或者推理出来你要从数组中找出一些什么，是不是有整数，是不是有空值？

2.能不能直接通过函数名告诉我你遍历这个数组是想干什么？

3.能不能直接通过函数名告诉我你想将什么替换成什么？

举个简单的例子，找出价格数组中是否存在整数价格。isInteger可能是已经有的公共函数，如果没有的话，经过你就有了。简洁易读，在阅读主流程的时候，有些代码是不需要阅读的，isInteger就是这样一些代码，万一有错呢？isInteger是可测易测的，如果你不放心，对它执行单元测试。你可能已经注意到，一个小小的改变，有一部分代码已经具有可测性了。即使这里不是一个公用函数，写成命名函数也更整洁更可测。

var isAnyInteger = priceArr.some(Common.isInteger.bind(Common));

这些都是非常极端的被认为是可以直接写匿名函数的例子，但很明显可以看到，他们也可以作为命名函数的边界处理，即都写命名函数百利而无一害，只会更好。

再简单的代码也要区分架构和实现

另外一个重灾区是 then 函数，匿名函数的代码不能更丑陋，即使大家都这么写，你也应该明白，你不能这么写，正确的姿势应该写成这样, 以展示订单为例：

/*
 * name        : getOrder
 * description : 获取订单数据
 */
function getOrder()
{//{{{
    var url = ‘https://www.qunar.com/getOrder‘;
    //假如收集参数比较费劲，应该用一个函数专门去收集参数
    var params = getOrderParams();
    //假如参数体比较庞大，应该先将其赋予一个变量
    var params = {
        orderNo:‘248663058‘
    };
    //无论如何，现将参数赋予变量你都将获得在这里打印变量方便调试的便利
    console.log(‘getOrder url & params:‘, url, params);
    return $.post(url, params);
}//}}}

/*
 * name        : renderOrder
 * description : 拿订单，拿到就在页面上展示出来，拿不到就告诉用户为什么没拿到
 */
function renderOrder()
{//{{{
    //高级函数，只安排工作，不自己实现
    //getOrder() 对该函数来说是不可见的，它要的只是订单数据，偷得抢的都可以
    getOrder().then(render, remindUser);
}//}}}

function render()
{//{{{
}//}}}

function remindUser()
{//{{{
}//}}}

当然，你可能觉得 renderOrder 就是鸡肋，跟只拿工资不干活的领导简直一毛一样，把then写在 $.post 后面不就行了？

不行，如果有一天获取订单既可以从本地获取，又可以从本地缓存获取，那么getOrder就升级为次高级函数，它管理两个函数 getOrderFromServer, getOrderFromCache

如果在获取订单之前或者之后还要做一些事情，那之后renderOrder能够从容应付。

想都不要想过度设计这个词，大部分人没有这个能力，不必杞人忧天。

你从一开始就是高级架构师只不过兼职写代码

你可以清楚的看到，大量使用命名函数让代码结构非常清晰，任何人都能容易的独懂主流程，任何人都可以容易的去实现每一个命名函数，要实现什么已经清楚的写在了函数名上了。

这些命名函数就像房屋的骨架，再往上堆叠就是一栋楼的骨架，你见过建筑设计师自己砌墙浇水泥的吗？写代码也一样，用函数堆叠成骨架，至于每个函数怎么实现，请帮我实现（在你初学的时候就是请你自己帮你自己实现）。

不要使用匿名函数