var func; 和 function func() {} 都是语法糖，会自动在变量范围开头声明变量为 undefined 。

闭包中引用的外部变量随时可能会有变化。闭包会保存各种环境状态，不宜长期保留，也不宜深度嵌套，以防内存泄漏。

传递数据时要注意数据是否为 primitive 类型，否则是引用传递。

定义全局变量时记得用 var （要在全局作用域定义），不要未经声明直接使用变量。定义全局变量来分享数据没什么不好的，用个 Object 模拟命名空间就行。
var MyProject = {};
MyProject.func = ...

太敏感。那是因为你很少关注其它职业的人死亡的新闻。

有可能是哗众取宠。只可惜没有提供折叠长篇内容的功能。详细一点没什么不好，更应该考虑网站的界面设计。

全是变态用法……不过幸好看到了 Array 的 filter 和 map 的一个值得注意的地方……
最让我无语的是 switch showCase1 那题，万万没想到啊……坑死了……虽然我想歪还答对了。=A=
其余的基本是搞笑题……叫我们不要过度依赖隐式转换。我用开了扩展语法的 Chrome 貌似验证不了 [].reverse 那题。20 / 40 Working Practitioner 我想这分数正常了……

这样子盯着屏幕长时间看小说会不会导致视力更差？

@fwee 的确有不少要注意的地方，不过代码已经够少够简单了。我介绍了的语法都已经能够正确产生解释树了。倒是没人帮忙给一些语法上的建议，我得自己思来想去的。

目前有三种语法还没仔细思考：raw HTML block, inline HTML block, 图片链接定义（不知道该用什么方法指定图片尺寸比较好，甚至指示图片类型）

*.loli.today 更牛，可惜至今仍未有人买。

@breeswish 已用过，还是有不少 bug 的，你翻翻看 issues 就知道了（我也参与过 bug 的讨论 https://github.com/chjj/marked/issues/298 ），而且作者似乎很忙，没多少时间维护代码。我正在写的转换工具就是参考他的代码的。

更何况 Markdown 没有严格标准。有很多规定都是大家自行定的，至今仍争吵不休。另外，斜体只用单个符号 * 或 _ 标记也是挺让人头痛的。长痛不如短痛，我写个新的，更严格的，类似的标记语言，大家要移植就移植。没有创新的话历史问题依旧会折磨更多的人。

@chenyg32 嘛，有时间就学吧，没时间就拿来玩吧。假如龙书内容太多一下子接受不下，可以看看下面两个资料：
http://compilers.iecc.com/crenshaw/ （免费，只是示例用的语言旧了点，不过可以用其它语言模仿）
http://createyourproglang.com（收费，仅提供部分免费章节，我没看过）

@jakwings 「人工智能也需要考虑和语言分析有关的编译原理，否则人工智能也只能停留在理论的领域。」改为「人工智能涉及的数据分析若没有合适的编译方法，难以提高效率。」

有时间的话值得学。可以提高对程序本质和代码运行效率的理解，深入对大型软件架构的思量，以后还可以自行改进其它人写的各种编译工具（大型或小型）。其实一个编译原理的方向已经包含了 N 多的知识，各种数据结构的运用。人工智能也需要考虑和语言分析有关的编译原理，否则人工智能也只能停留在理论的领域。当然人工智能的理论是编译原理课程不会说的。
以上纯属个人对大牛的羡慕引发的评论。

@msg7086 谢～我竟然忘了还有不允许的字符可以作为替换。至于正则，由于 JS 的正则表达式没有负向预查语法，所以最多只能用 (\\[\^|]|[\^|]|.) 循环匹配来模拟状态机了。

不过用循环替换文本再切割再替换回来的方法，也要对分割出来的数组进行循环操作，总共循环了两次，还是直接写个一次循环的状态机比较好了。

@fwee 我明白 Parser 不是越容易写越好。

再舒服也不希望自己把源代码写得一塌糊涂吧？我的 Parser 写得既舒服，也不会对文章的编写造成多少影响。我目前写的语法说明草稿不是面向初学者的，读起来可能比较难理解。

我的目标是完成 Javascript 前后端的转换工具，摆脱没有良好标准的 Markdown 。我的转换工具也会提供类似 GFM 的功能选项。具体计划可以看这里：
https://embed.coggle.it/diagram/5307d7a444d6243f76078bbe/ae602abb9b08afe0ea52aa6f58473ece507ea4facabc2253f4eb920f114eab12#structural-blocks

下方自动隐藏。只摆放常用软件（不多于 10 个），不常用的按类型摆放于 Launchpad 。