Home >Web Front-end >JS Tutorial >Reasons not to use JS anonymous functions
This article analyzes the three major reasons not to use jsanonymous functions. The function of JS anonymous functions is to avoid the pollution of global variables and the conflict of function names. About js anonymous Please refer to this article for the three major reasons for functions.
The basic form of anonymous functions is(function(){...})();
Before The parentheses contain the function body, and the following parentheses are to pass parameters to the anonymous function and execute it immediately.
The function of the anonymous function is to avoid the pollution of global variables and the conflict of function names
No matter Whenever you read code, you must be aware of anonymous functions. Sometimes they are called lambdas, sometimes anonymous functions, either way I think they are difficult to use.
If you don’t know what an anonymous function is, here’s a quote:
An anonymous function is a function that is dynamically declared at runtime. They are called anonymous functions because unlike ordinary functions, they do not have function names. — Helen Emerson, Helenephant.com
The form of an anonymous function is as follows:
function () { ... code ... } OR (args) => { ... code .. }
I am trying to make everyone understand today the idea of generally only using anonymous functions when absolutely necessary. Anonymous functions should not be preferred and should be used only if the reasons are known. When you understand this idea, your code will become cleaner, easier to maintain, and easier to track bugs. Let’s start with three reasons to avoid using anonymous functions: When you write code, no matter how good you are at typing code, you will always encounter errors. Sometimes these errors are easy to detect, sometimes not.
If you know where these errors come from, then the errors can be easily detected. To find errors, we use this tool called a stack trace. If you don't know about stack traces, Google has a great introduction.
Suppose there is a very simple project now:
function start () { (function middle () { (function end () { console.lg('test'); })() })() }
There is a very stupid mistake in the above code, a spelling mistake (console.log). In a small project, this spelling error is not a big problem. If this is a small section of a very large project with many modules, the problem is huge. Assuming you didn't make this stupid mistake, the new junior engineer will commit it to the code base before he goes on vacation!
Now, we must track it down. Using our carefully named function, we get the following stack trace:
Thanks for naming your functions, junior developers! Now we can easily track down the bug.
But... once we solved this problem, we found that there was another bug. This time it was from a more senior developer. This person knows about lambdas
As a result they stumble upon a bug and it's our job to track it down.
The following is the code:
(function () { (function () { (function () { console.lg('test'); })(); })(); })();
Not surprisingly, this developer also forgot how to spell console.log! This is too much of a coincidence! It's a shame that none of them named their functions.
So what will the console output?
Well, we at least still have line numbers, right? In this example, it looks like we have about 7 lines of code. What happens if we deal with a large block of code? Like ten thousand lines of code? What should we do if the span of line numbers is so large? If there is a code
mapfile after the code is folded, then is the rendering of line numbers useless at all? I think the answer to these questions is quite simple. The answer is: thinking about these things will make your whole day miserable.
ReadabilityHey, I heard that you still don’t believe it. You're still attached to your anonymous function, and the bug has never occurred. Well I have to apologize to you for thinking your code is perfect. Let's take a look at this!
Look at the following two pieces of code:
function initiate (arguments) { return new Promise((resolve, reject) => { try { if (arguments) { return resolve(true); } return resolve(false); } catch (e) { reject(e); } }); } initiate(true) .then(res => { if (res) { doSomethingElse(); } else { doSomething(); } ).catch(e => { logError(e.message); restartApp(); } );
This is a very abnormal example, but I believe you already understand what I am going to say. Our method returns a promise, and we use this promise
Object/method to handle different possible responses. You may think that these few pieces of code are not difficult to read, but I think they can be better!
What would happen if we removed all anonymous functions?
function initiate (arguments) { return new Promise(checkForArguments); } function checkForArguments (resolve, reject) { try { if (arguments) { return resolve(true); } return resolve(false); } catch (e) { reject(e); } } function evaluateRes (res) { if (res) { doSomethingElse(); } else { doSomething(); } } function handleError (e) { logError(e.message); restartApp(); } initiate(true) .then(evaluateRes) .catch(handleError);
Okay, let’s be clear: this part of the code is longer, but I think it’s more than just more readable! Our carefully named functions are different from anonymous functions in that we know what their function is as soon as we see their name. This avoids obstacles when evaluating code.
This also helps to clarify the relationship. Instead of creating a method, passing it in, and then running the logic, in the second example the arguments are given to then and catch just points to the function where everything happens.
There’s nothing more I can say to you about being more readable. But maybe if you're not convinced yet, I can try one final argument.
related suggestion:
Template method singleton in javascript
Detailed explanation of javascript to determine whether the user has operated the page
Use JavaScript to implement a small program 99 multiplication table
The above is the detailed content of Reasons not to use JS anonymous functions. For more information, please follow other related articles on the PHP Chinese website!