问题描述
我是 JavaScript 新手.我了解该语言的许多概念，我一直在阅读原型继承模型，并且我正在用越来越多的交互式前端内容来吹口哨.这是一种有趣的语言，但我总是对许多非平凡交互模型的典型回调意大利面有点反感.
I'm new-ish to JavaScript. I understand many of the concepts of the language, I've been reading up on the prototype inheritance model, and I'm whetting my whistle with more and more interactive front-end stuff. It's an interesting language, but I'm always a bit turned off by the callback spaghetti that is typical of many non-trivial interaction models.
对我来说一直很奇怪的事情是，尽管 JavaScript 嵌套回调嵌套的可读性噩梦，但我在许多示例和教程中很少看到的一件事是使用预定义的命名函数作为回调论据.白天，我是一名 Java 程序员，并且摒弃关于代码单元的 Enterprise-y 名称的刻板印象 使用具有大量功能强大的 IDE 的语言工作时，我喜欢的一件事是，使用有意义的名称(如果很长)可以使代码的意图和含义更加清晰，而不会使实际操作变得更加困难富有成效.那么为什么在编写 JavaScript 代码时不使用相同的方法呢?
Something that has always seemed strange to me is that in spite of the readability nightmare that is a nest of JavaScript nested callbacks, the one thing that I very rarely see in many examples and tutorials is the use of predefined named functions as callback arguments. I'm a Java programmer by day, and discarding the stereotypical jabs about Enterprise-y names for units of code one of the things I've come to enjoy about working in a language with a strong selection of featureful IDE's is that using meaningful, if long, names can make the intent and meaning of code much clearer without making it more difficult to actually be productive. So why not use the same approach when writing JavaScript code?
仔细想想，我可以提出支持和反对这个想法的论点，但我对语言的天真和新奇使我无法得出任何关于为什么这在技术层面上会很好的结论.
Giving it thought, I can come up with arguments that are both for and against this idea, but my naivety and newness to the language impairs me from reaching any conclusions as to why this would be good at a technical level.
- 灵活性.一个带有回调参数的异步函数可以通过许多不同的代码路径之一访问，并且可能不得不编写一个命名函数来解释每个可能的边缘情况.
- 速度.它在很大程度上影响了黑客的心态.把东西固定在上面，直到它起作用为止.
- 其他人都在这样做
- 文件更小，即使微不足道，但网络上的每一点都很重要.
- 更简单的 AST?我假设匿名函数是在运行时生成的，因此 JIT 不会将名称映射到指令，但我现在只是猜测.
- 更快的调度?也不确定这个.再猜一次.
- 它很丑陋且无法阅读
- 当您在回调沼泽深处嵌套疯狂时，这会增加混乱(公平地说，这可能意味着您开始编写结构不佳的代码，但这很常见).
- 对于没有功能背景的人来说，理解它可能是一个奇怪的概念
有这么多现代浏览器显示出比以前更快地执行 JavaScript 代码的能力，我看不出使用匿名回调可能会获得任何微不足道的性能提升是必要的.似乎，如果您处于使用命名函数可行的情况(可预测的行为和执行路径)，那么就没有理由不这样做.
With so many modern browsers showing the ability to execute JavaScript code much faster than before, I'm failing to see how any trivial sort of performance gain one might get out using anonymous callbacks would be a necessity. It seems that, if you are in a situation where using a named function is feasible (predictable behavior and path of execution) then there would be no reason not to.
那么是否有任何我不知道的技术原因或陷阱导致这种做法如此普遍?
So are there any technical reasons or gotchas that I'm not aware of that makes this practice so commonplace for a reason?
推荐答案
我使用匿名函数有以下三个原因:
I use anonymous functions for three reasons:
- 如果因为函数只在一个地方被调用而不需要名称，那么为什么要为您所在的任何命名空间添加一个名称.
- 匿名函数被声明为内联，而内联函数的优势在于它们可以访问父作用域中的变量.是的，您可以为匿名函数命名，但如果它被声明为内联函数，则通常毫无意义.因此内联具有显着的优势，如果您进行内联，则没有理由在其上命名.
- 当处理程序在调用它们的代码中定义时，代码看起来更加独立和可读.您可以几乎按顺序阅读代码，而不必去查找具有该名称的函数.
我确实尽量避免匿名函数的深层嵌套，因为这可能很难理解和阅读.通常，当这种情况发生时，有更好的方法来构建代码(有时使用循环，有时使用数据表等)，而命名函数通常也不是解决方案.
I do try to avoid deep nesting of anonymous functions because that can be hairy to understand and read. Usually when that happens, there's a better way to structure the code (sometimes with a loop, sometimes with a data table, etc...) and named functions isn't usually the solution there either.
我想我会补充一点，如果回调开始超过 15-20 行，并且不需要直接访问父作用域中的变量，我会很想给它一个名称并中断它进入它自己在别处声明的命名函数.这里肯定有一个可读性点，如果将一个很长的非平凡函数放在自己的命名单元中，它会更易于维护.但是，我最终得到的大多数回调都没有那么长，而且我发现将它们保持内联更具可读性.
I guess I'd add that if a callback starts to get more than about 15-20 lines long and it doesn't need direct access to variables in the parent scope, I would be tempted to give it a name and break it out into it's own named function declared elsewhere. There is definitely a readability point here where a non-trivial function that gets long is just more maintainable if it's put in its own named unit. But, most callbacks I end up with are not that long and I find it more readable to keep them inline.
这篇关于对于 JavaScript 事件代码中的回调和参数，使用匿名函数而不是命名函数有什么好处?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！