简单的坑，noder看过来
发布于 6个月前 作者 ngot 1578 次浏览 
console.log("func 1");
})();

console.log("in global");

(function() {
    console.log("func 2");

亲们，请问执行结果是什么？ 能够解释一下为什么吗？

73 回复

有点像自己喝了毒药，死了还问为什么

@ngot 你是说它不报错还是？

@coolicer 包裸代码这一点

有点意思

跑起来了…

看源代码：

Node:

  NativeModule.wrap = function(script) {
    return NativeModule.wrapper[0] + script + NativeModule.wrapper[1];
  };

  NativeModule.wrapper = [
    '(function (exports, require, module, __filename, __dirname) { ',
    '\n});'
  ];

fibjs:


inline result_t _error_checker(result_t hr, const char *file, int line)
{
    if (hr < 0 && hr != CALL_E_NOSYNC && hr != CALL_E_NOASYNC && hr != CALL_E_PENDDING)
    {
        std::string str = file;
        char tmp[64];

        sprintf(tmp, ":%d ", line);
        str.append(tmp);

        asyncLog(3, str + getResultMessage(hr));
    }

    return hr;
}

#define CHECK_ERROR(hr) _error_checker((hr), __FILE__, __LINE__)

CHECK_ERROR(CALL_E_JAVASCRIPT);

@ngot 坑出现了。 = =，感觉本身JS也有坑，没有规范的话还是看个人习惯。

@ngot 不明觉厉

@ngot

你该买本<<javascript:the good part>>好好学习学习， js不是一两年就能懂得

@tulayang 不过他说的确实是个坑，看4#

@coolicer

装jslint jshint

@tulayang 你懂我在说什么？

@tulayang 你的理解力，还需加强。

@tulayang 你看看4楼就知道了

我在说vm，他跟我谈js。无力…

这是何解。。。？

@ngot 是我误导人家，我也没看标题。

@tulayang 好像，就你读过一样。

@ngot

我自然是读过的。

@gvforjob 根本原因是node在包裹代码前没有做语法检查，直接包裹了裸代码。按照@tulayang 的逻辑，这是写js代码的人，sb，不是伟大的node的问题，node怎么可能有问题呢。

@ngot

说你不懂js，你还真能秀自己多不懂，好好看看《javascript:the good part》。

js不是菜鸟就可以用的。 js不是java、c++，有管家给你写好了各种框子，小朋友也可以持家。 js更像是c、lisp。 我想学c的人都知道看看《c缺陷与陷阱》。

@tulayang 不要到处秀下限。

@ngot

我觉得你也该好好看看Linus Torvalds是怎么骂C++的，那场面极其宏大。

@tulayang 我明白了。呵呵。

要是一个bug就能说明node弱爆了，你给我找个不弱爆的语言/平台出来

@ravenwang 找不出来。忽视我的废话…

这人是在这推广fibjs的, 你推广fibjs我无话可说, 但是任何一个伟大的人都不会把巨人踩在脚底下来显示自己有多伟大, 顺道说一句, 你以为就你这种素质就能把fibjs推广? 可笑, 低调点吧! 任何语言, 都是一步一步完善起来的, javascript就是脚本语言, 解释执行, require时候检查代码的合法性是要付出计算成本的, 你以为只有你能想到?

这说明node的包容

@xujun52011 你说的对，谢谢批评。我只是想指出一些大家可能未关注的地方。

@Hi-Rube 非要这么想，也是可以的。

@xujun52011 你，说到问题关键点上了。上面某位大牛，跟我争半天，不知道在争什么。计算开销确实是个问题。但如果从减少编码潜在的坑角度来看，还是可取的。而且，计算开销只在系统初始化时增加，应该还算可接受。从node一贯设计哲学来看，有可能真的是出于加快初始化速度考虑，而不做检查。但是这就，留坑给开发者了，这和利用回调追求异步这个大坑一样一样的。关于**js的，我就不多说了，一句话，node挖坑，咱填坑(我们认为的坑)。

@ngot 某人说语法糖可以解决。coffee

我还算是知道node的包引入机制，不算是没研究过。但想到这么用的，你也可以进“不正常人类研究院-nodejs分院”了。不过我突然就在想，下面一段是

(function (exports, require, module, __filename, __dirname) { console.log(“func 2”);

会是怎么回事了。。。

我觉得这不是坑，一个小BUG而言。而且它对代码没有什么实质性的害处

我觉得这和这么写jQuery代码是一个道理：

$.fn.init = 'test';

你非要这么写，那也没办法，但你不能说他是jQuery的坑吧。

m1.js

console.log("func 1");
})();

var v = "v22222222";

(function() {
    console.log("func 2");

m2.js

require("./m1.js");

console.log(v);

执行结果：

func 1
func 2
v22222222

目前发现会造成全局变量污染。总感觉，还有妙用。待研究。

@roychad7 会报错。

@wuliao49 目前发现会污染全局变量。其他伤害待研究。

@ngot 我的意思是 真正写代码的时候不会出现这种代码，概率几乎为0，所以没有什么危害。 而且node的全局变量有专门的定义方式，不会受到这个的影响。

@wuliao49 我想利用这个特性，干坏事。

@ngot 12楼的代码，就可以污染全局变量。

又被转过来了。

使用工具就像谈恋爱，你爱一个人，就连她的缺陷都会觉得可爱。但是客观来说，缺陷就是缺陷。

比如下面这段代码：

var a = 10, b = 20, c = 30;

func1(a, b, c, function() {
    func2(a, b, c, function() {
        func3(a, b, c, function() {
            func4(a, b, c, function() {
                func5(a, b, c, function() {
                    func7(a, b, c, function() {});
                    });
                });
            });
        });
    });
});

func1(a, b, c, function() {
    func2(a, b, c, function() {
        func3(a, b, c, function() {
            func4(a, b, c, function() {
                func5(a, b, c, function() {
                    func6(a, b, c, function() {
                        func7(a, b, c, function() {});
                });
            });
        });
    });
});

function func1(a, b, c, fn) {
    fn();
}

function func2(a, b, c, fn) {
    fn();
}

function func3(a, b, c, fn) {
    fn();
}

function func4(a, b, c, fn) {
    fn();
}

function func5(a, b, c, fn) {
    fn();
}

function func6(a, b, c, fn) {
    fn();
}

function func7(a, b, c, fn) {
    fn();
}

在 node 里面会报：

func1(a, b, c, function() {
      ^
ReferenceError: a is not defined
    at /Users/lion/Documents/projects/temp/test.js:16:7
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3

在 fibjs 里面会报：

Unexpected token }
    at test.js:12:1

你们说说那个会让你的工作效率更高？

哈哈 有意思

@alsotang 看楼上各位的回复，好像都没跟楼主在讨论一个话题啊…人家虽然有在推广 fibjs，但也没必要不就事论事啊。

谢谢

看起来就是加了一个语法校验而已，有必要另起锅灶吗？

一个问题不大的bug。 如果说利用这个东西来做坏事，那么水平也太低了。

@ngot 其实各有优劣吧, 再者说一点, 随便一个ide都能检查出你上面那段不合法的代码的错误, 当然, 你要跟我说notepad, 那我无话可说, 当我没说

ps:最近也在研究fibjs, 可恨c++只懂皮毛, 慢慢学吧.

@xicilion 你这段代码, 一放到ide里面就报错了, notepad++一样, 当然, 我是低端码农, 不会用notepad写代码, 再者, 跟我回复上面某位一样, 如果require需要检查代码的合法性的话, 是要付出运算成本的.

@wuliao49 这只是个很小的小细节。

楼主各种黑node.js啊，简单看了下源码，fibjs把gd库，redis，mongodb，mysql等许多第三方软件的驱动都维护到自己的fibjs里的，fibjs整合了大部分web用到的工具，而不必像node.js一个个package的去安装，更像一个整合了好多工具的express，由于很多框架逻辑，工具都是通过c++来编写的，所以性能肯定会好于node.js，但是随着业务代码的深入，这方面优势我想会越来越少。而且有2点，表示对fibjs的前途心存忧虑： 1、这么多工具库，还有fibjs的稳定性，bug测试，新功能开发等等，不知道fibjs研发团队有多少人，能有这么多精力来做这个事情，这是准备累死自己的节奏； 2、node.js的语法已经深入人心，推出一个api相似，但又不尽相同的平台是否明智，如果使用的人不多，没有大项目助威，投资不给力，那问题1就更大了；

@snoopy fibjs 是孢子社区的基础运行平台，目前已经持续开发两年多，完整的孢子应用在线运行一年多。未来这个项目会与孢子社区一起发展。

@alsotang 如果，我黑一个别人一直信仰的东西，具体黑什么，他们不会关心。只会，指着你问：你有什么资格来说三道四？你真的懂吗？ 然后，就歪楼了。

＠ngot 的两个帖子（另一个：fibjs比 nodejs 快五倍，本来是孢子论坛fibjs兴趣组的帖子，本来是作者@xicilion 在自己的地盘上为自己的工作分享自己的一些开心，可能被转到这里后产生了一点点踢馆砸场子的感觉？＠ngot 在前一个帖子里面也许言辞激烈了些，这次感觉就平和多了，其实如果有精力，多一个项目大家玩玩不是挺好的么？没有精力的话，简单忽视也就好了，也都大可不必好像非此即彼一样的。看了个帖子能够有点收获，不是也不错？
程序员都有批判的基因，不过了解过后的批判，不是才更有价值和说服力么

换个角度想想，国人CPU靠过谱么？国人OS靠过谱么？国人的普及泛用型编程语言有么？和各种“麒麟OS/kylin”，“易语言”，“狗剩”（这个还在期待。。。)比起来,fibjs至少：

  • 有创新
  • 不浮躁，不功利，持续活跃
  • xicilion发起，无政府背景，不忽悠，不花纳税人的钱

fibjs项目会怎么发展下去那是顺其自然的事，可以观望也可以参与， 不过国人的项目不支持下，然后又各种场合感慨国人不给力，也不好吧。。。

@xicilion

这种代码检查方法都是搞笑的，Douglas Crockford早就在许多年前就发明了类似C Lint的JSLint，想要严格的代码审查，使用JSLint子集。

你对nodejs的这些认识，建立在你对js不认识的基础上，而且我也非常清楚这种js半生不熟的人士非常之多。

我记得有位老外哥们说过一句豪语，“凡是可以用 JavaScript 来写的应用,最终都会用 JavaScript 来写。” 虽然夸张了点，不过也挺有些意味。现在正是一个时代的变迁，java、c++、c#、面向对象的衰落以及scala、f#、函数式对象混合的兴起。

@ngot

这种想法真是幼稚，除非你想黑一下那种专门留给别人注入代码的菜鸟。 不说js，但就sql就一大堆防止注入的代码准则。 再说js，除非那个菜鸟使用new Function()和eval。

@tulayang 用你的逻辑，回复你一下。用JsLint来检查代码，是搞笑的，因为响马早就研究出了，运行前代码检查。想要，严格的代码检查，请在运行前自动检测。对仗工整，赞一个。什么逻辑～～

@ngot

我拜托你先搞懂什么是JsLint。

一个JsLint都不懂的人，我觉得没有什么可以跟你谈js的价值。 你的这句话充满了编程幼稚。

@tulayang 参见14楼，回复。

@ngot

不用参见不参见，想做js的底层东西，拜托你先把js的常识功课做足了。

@tulayang 黑了你的上帝，全能神，抱歉，我道歉。幸亏，我不在麦当劳，不然，你要跟我要号码了。

@ngot

呵呵，我觉得黑你真是一种浪费，至少你不到黑的水平。 因为你连编程的常识都不具备。

@tulayang 浪费，您宝贵时间了。抱歉。

@ngot

自己狂不是真的狂，自己说好不是真的好，而且这么多年我真没见国内出过一个像样的代码。

@zalemwoo 说的很有道理~

linux 一开始也不如现在这么强大

这人应该是看了node源码，专门找茬来着呢

@xicilion 跑了两年多又怎样呢? 业务场景单一, 很多bug都无法被发现!

@xujun52011 哑口无言。

你们这些人啊。软件有bug有缺陷是很正常不过的事情。要不然怎么会有contributor的存在呢。

觉得这个就黑了node什么的，实在是玻璃心。node也是在借鉴一些东西的基础上开发出来的，同样fibjs也是。难道有了fibjs之后，写node的人就不能好好的玩耍了么。node开放得早，传播范围广，它的一些设计上的缺陷，可以在后来者中避免。同样，人家找出Node的一处bug（也许压根就不用fix），没必要就吵来吵去的，更应该做的是这样的bug如果能在现在的node中修复，请去官方提issue： https://github.com/joyent/node/issues/new 。在原则性上无法更改的事情，那就包容。

@JacksonTian 非常在理。我转这个过来就是想让大家，换个角度看node.可是很多人，不愿意去思考为什么。第一反应就是：你是谁？ 你凭什么说三道四？ 维护心中偶像的冲动，完全冲昏了本该独立思考头脑。

@ngot 承认吧其实你就是想来砸场子滴

@ravenwang 真不是。砸场子，得有实力。我还差得远。我只是来水一下.

回到顶部