$scope.del = function () { var delItemId = getDelId(); // 要删除的项目的身份标识 // 如果没选择删除项 if (!delItemId.length) { $promptLayer.show({ str: $message.delItemIsEmpty }); return; } delTarArr = delItemId; $weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn); }; // 确认删除 $rootScope.$on('androidDialog2Btn1', function () { del( delTarArr.join(',') ); $weuiAndroidDialog2.hide(); }); // 取消删除 $rootScope.$on('androidDialog2Btn0', function () { $weuiAndroidDialog2.hide(); }); var delTarArr; // 获取要删除项标识 function getDelId() { var delTarArr = []; $angular.forEach($scope.selectAllItem, function (v, i) { if (v) { delTarArr.push($scope.storeList[i].Sid); } }); return delTarArr; } // 删除 function del(param) { // 请求删除接口 $handler.store.del( param ).then(function () { delAllJumpPage(delTarArr.length, $scope.selectAllItem.length); // 删空跳页 }); } // 删空跳页 function delAllJumpPage(delNum, totalNum) { var curPage = $scope.pageControlCurNum; // 当前所在页数 // 此页删空 跳上一页 if (delNum === totalNum) curPage = curPage - 1; $scope.loadList(curPage); $scope.pageControlCurNum = curPage; }or
var delTarArr; $scope.del = function () { // 看是否有选中项 $angular.forEach($scope.selectAllItem, function (v, i) { if (v) { delTarArr.push($scope.storeList[i].Sid); // 获取选中项 Sid } }); // 如果没有删除项 if (!delTarArr.length) { $promptLayer.show({ str: $message.delItemIsEmpty }); return; } // 再次确认提示层 $weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn); }; // 确认删除 $rootScope.$on('androidDialog2Btn1', function () { // 请求删除接口 $handler.store.del( delTarArr.join(',') ).then(function () { // 删空跳页 var curPage = $scope.pageControlCurNum; // 当前所在页数 // 此页删空 跳上一页 if (delTarArr.length === $scope.selectAllItem.length) curPage = curPage - 1; $scope.loadList(curPage); $scope.pageControlCurNum = curPage; }); $weuiAndroidDialog2.hide(); }); // 取消删除 $rootScope.$on('androidDialog2Btn0', function () { $weuiAndroidDialog2.hide(); });这两段代码哪个相对较优一点…… 虽然都挺渣的 大佬们对付看吧
一个函数只能干一件事这么做是为什么 可读性？扩展性？复用性？在我看来声明函数也不是没有成本的啊 一个函数就占内存的一些空间呢 调用函数也没有直接解析来的快吧~
如果是为了复用、扩展的话 第一次写的时候就这样做的真的不是提前优化吗 以后的需求都确定不了呢 怎么知道提出的函数放在未来是通用的呢 这样看绝对不是最佳性能的实践啊~
提前 / 过渡优化不是万恶之源吗？~
就一个类而言，应该仅有一个引起它变化的原因。在 JavaScript 中，需要用到类的场景并不
太多，单一职责原则更多地是被运用在对象或者方法级别上，因此本节我们的讨论大多基于对象
和方法。
单一职责原则（SRP）的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一
个方法，那么这个方法就具有两个职责。每个职责都是变化的一个轴线，如果一个方法承担了过
多的职责，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。
此时，这个方法通常是一个不稳定的方法，修改代码总是一件危险的事情，特别是当两个职
责耦合在一起的时候，一个职责发生变化可能会影响到其他职责的实现，造成意想不到的破坏，
这种耦合性得到的是低内聚和脆弱的设计。
因此， SRP 原则体现为：一个对象（方法）只做一件事情。
谈一下个人见解，程序是给人读的，一个函数的复杂度越高，读通的成本就越高。即使是你写的程序，几个月后，看懂其中的意思可能就需要一会儿，何况别人也可能接手你的代码！
程序先让人看懂了，再谈运行的性能优化
如果你的代码只需要用很短的时间，不需要以后迭代，不需要提供给其他同事用，也不需要单元测试，那么随便写吧，功能实现就行了。
如果你的代码需要被其他同事调用，需要进行迭代，需要扩展，需要单元测试。那还是按照规范来做吧，性能从来就不是代码的形式决定的。
最简单的方法，如果你的代码隔一个月以后自己来看，发现很难阅读，很难维护，很难扩展，那还是重构吧。
我认为一个函数只干一件事更好 .... 鬼知道这些阴险的函数会不会到处散播副作用 ...
还是只做一件事，最后把他们黏连起来使用比较好。
还有我不认为性能上有很大差距 也许一个函数只干一件事性能还会更好。
第一段代码相比第二段的一个明显特点就是 每个函数的平均行数少了，第二个平均行数比较多。
维护编写短小的代码心智负担比较小 从而维护编写的效率高
只做一件事意味着 这个函数只要能做完这件事就可以了， 你可以轻而易举地用别的算法实现的这个函数的副本直接替换。
由于编写了众多短小精悍的小函数，组装的时候抽象层次会高一些，更符合思考。
为了复用、为了拓展从来都不是
提前优化，相反，更应该重视这两个你说得没错。就是为了可读性、扩展性、和复用。最主要还是可读性/可维护性。干多件事情的函数你都没法起名呢，更别说让别人理解了。
过早优化是这个：「一个函数就占内存的一些空间呢」。