javascript - Minimum Function Principle A function can only do one related thing. Why? Does it really make sense? ~

Question

$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();
});

Which of these two pieces of code is better... Although both of them are quite scumbag, let’s deal with them

A function can only do one thing. Why is it so readable? Scalability? Reusability? In my opinion, declaring a function is not cost-free. A function only takes up some space in the memory. Calling the function does not require direct analysis, so it is faster~

If it is for reuse and expansion, is it really not optimization in advance to do this when writing for the first time? The future needs cannot be determined? How do you know that the proposed function will be universal in the future? From this perspective, it is definitely not the case. Best performance practices~

Isn’t advance/transition optimization the root of all evil? ~

Answer 1

As far as a class is concerned, there should be only one reason for its change. In JavaScript, there are not too many scenarios that require the use of classes. The single responsibility principle is more often applied at the object or method level, so our discussion in this section is mostly based on objects and methods.
Responsibility in the Single Responsibility Principle (SRP) is defined as “the cause of change”. If we have two motivations for overriding a method, then this method has two responsibilities. Each responsibility is an axis of change. If a method takes on too many responsibilities, the greater the possibility that the method will need to be rewritten as requirements change.
At this time, this method is usually an unstable method, and modifying the code is always a dangerous thing, especially when two responsibilities are coupled together, changes in one responsibility may affect the implementation of other responsibilities , causing unexpected damage,
This coupling results in a low cohesion and fragile design.
Therefore, the SRP principle is embodied as: an object (method) only does one thing.

Answer 2

Let me talk about my personal opinion. Programs are for people to read. The higher the complexity of a function, the higher the cost of reading it. Even if you write a program, it may take a while to understand its meaning a few months later, not to mention that others may take over your code!

Let people understand the program first, and then talk about optimization of running performance

Answer 3

If your code only needs to be used for a short time, does not need to be iterated later, does not need to be provided to other colleagues, and does not need unit testing, then just write it casually and implement the function.

If your code needs to be called by other colleagues, it needs to be iterated, extended, and unit tested. Then just follow the specifications. Performance is never determined by the form of the code.

The simplest way is, if you look at your code after a month and find it difficult to read, maintain, and expand, then refactor it.

Answer 4

I think it’s better for a function to only do one thing... Who knows if these insidious functions will spread side effects everywhere...
It’s better to only do one thing and finally connect them together for use.

Also, I don’t think there is a big difference in performance. Maybe a function that only does one thing will perform better.

---

1. One obvious feature of the first piece of code compared to the second piece of code is that the average number of lines per function is less, while the average number of lines of the second piece is more.

2. The mental burden of maintaining and writing short codes is relatively small, so the efficiency of maintenance and writing is high

3. Doing only one thing means that this function only needs to be able to complete this task, and you can easily replace it directly with a copy of this function implemented by another algorithm.

4. Due to writing many short and concise small functions, the abstraction level will be higher during assembly, which is more suitable for thinking.

---

If it’s for reuse and expansion, isn’t doing this the first time you write it really an optimization in advance?

For reuse and expansion, it is never optimize in advance. On the contrary, we should pay more attention to these two

Answer 5

You are right. It's for readability, scalability, and reuse. The most important thing is readability/maintainability. You can’t even name a function that does multiple things, let alone make others understand it.

Premature optimization is this: "A function takes up some space in the memory."