关于Node的代码风格 [英] About Node's code style
问题描述
编辑
thx到所有答案，\\
最后我决定使用一些工具， a href =https://github.com/creationix/step =nofollow>步骤，
我需要的全部是流量控制，不想要任何可能会降低性能的东西（我不知道它会影响多少，或者效果只是可以忽略）。
所以我只是创建一个流程控制工具：
line.js
/ **
*创建下一个函数
*
* @param {Array} tasks
* @param {Number} index
* @param {Number} last
* /
var next = function（tasks，index，last）{
if（index == last）{
return tasks [index + 1];
}
else {
返回函数（数据）{
var nextIndex = index + 1;
tasks [nextIndex]（next（tasks，nextIndex，last），data）;
};
}
};
/ **
*调用函数。
* /
module.exports = function（）{
var tasks = arguments，
last = tasks.length - 2;
tasks [0]（next（tasks，0，last））;
};
用法：
code> varline = require（line.js）;
line（function（next）{
someObj.find（function（err，docs）{
// codes
next
}）;
}，function（next，docs）{
// codes
}）;
希望这有帮助。
编辑结束
b $ b Node的内置模块或第三方模块通常提供异步API，`
'并使用callback函数来处理结果。
它很酷，但有时会这样编码：
//一些代码
}
}
}
}
这样的代码很难阅读。
我知道deferred库可以解决这个问题，
Node有没有好的deferred模块？
和How是如果我用deferred代码Node编程的性能？
基于节点的代码;你经常成长回调金字塔。处理此问题有几种方法：
代码样式：
使用这个烦恼作为一个机会，把你的代码分成小块的大块。这意味着你可能会有一个小的命名funcs - 这可能是好的，但！
$ b
流控制库
在那里有正确的5937.2亿流量控制库。以下是一些更受欢迎的：语言扩展
尝试在JavaScript（或CoffeeScript）之上提供更具同步感的语法，通常基于 tame paper 。
p>
- 这不是标准的JavaScript;
- 根据库的不同，变量范围可能以意想不到的方式表现。
如果您正在构建库/框架/ li>生成的代码可能很难调试&
节点核心团队非常清楚这个问题，并且正在开发低级别组件以帮助缓解疼痛。看来他们将在v0中引入基本版本的网域 .8，它提供了一种滚动错误处理的方法（避免常见的 return err如果err 模式，主要）。
这应该开始为清洁的流控制库奠定一个伟大的基础，并开始为更一致的方式处理回调金字塔铺平道路。
参考文献：
EDIT
thx to all the answers,
and finally I decide to use some tools like Step,
all I need is "flow control" and don't want any thing else which may slow down the performance (I don't know how much exactly it would effect or the effect just can be ignored).
So I just create a little tool for flow control:
line.js
/**
* Create the "next" function
*
* @param {Array} tasks
* @param {Number} index
* @param {Number} last
*/
var next = function(tasks, index, last) {
if (index == last) {
return tasks[index + 1];
}
else {
return function(data) {
var nextIndex = index + 1;
tasks[nextIndex](next(tasks, nextIndex, last), data);
};
}
};
/**
* Invoke functions in line.
*/
module.exports = function() {
var tasks = arguments,
last = tasks.length - 2;
tasks[0](next(tasks, 0, last));
};
usage:
var line = require("line.js");
line(function(next) {
someObj.find(function(err, docs) {
// codes
next(docs);
});
}, function(next, docs) {
// codes
});
Hope this helps.
EDIT END
As all know,
Node's built-in or third-part modules often provides async API,
and using "callback" function for dealing the results.
It's cool but sometimes would code like this:
//some codes
}
}
}
}
codes like this are hard to read.
I know "deferred" library can solve such problem,
Is there any good "deferred" module for Node?
And How is the performance if I code Node with "deferred"?
It is a large problem with Node-based code; you frequently grow "callback pyramids". There are several approaches to dealing with the problem:
Code style:
Use this annoyance as an opportunity to break your code into bite sized chunks. It means you're likely going to have a proliferation of tiny named funcs - that's probably just fine, though! You might also find more opportunities for reuse.
Flow-control Libraries
There are exactly 593.72 billion flow control libraries out there. Here's some of the more popular ones:
- Step super basic serial & parallel flow management.
- seq is a heavier but more feature-full flow control library.
- There's plenty more. Search the npm registry for "flow" and "flow control" (sorry, doesn't appear to be linkable)
Language Extensions
There are several attempts to provide a more synchronous-feeling syntax on top of JavaScript (or CoffeeScript), often based on the concepts behind the tame paper.
- TameJS is the OkCupid team's answer to this.
- IcedCoffeeScript they've also ported TameJS over CoffeeScript as a fork.
- streamline.js is very similar to TameJS.
- StratifiedJS is a heavier approach to the problem.
This route is a deal-breaker for some:
- It's not standard JavaScript; if you are building libraries/frameworks/etc, finding help will be more difficult.
- Variable scope can behave in unexpected ways, depending on the library.
- The generated code can be difficult to debug & match to the original source.
The Future:
The node core team is very aware of the problem, and are also working on lower level components to help ease the pain. It looks like they'll be introducing a basic version of domains in v0.8, which provide a way of rolling up error handling (avoiding the common return err if err pattern, primarily).
This should start to lay a great foundation for cleaner flow control libraries, and start to pave the way for a more consistent way of dealing with callback pyramids. There's too much choice out there right now, and the community isn't close to agreeing on even a handful of standards yet.
References:
- Mixu's Node book has an awesome chapter on this subject.
这篇关于关于Node的代码风格的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
