在[url]http://bbs.51js.com/viewthread.php?tid=83937&extra=page%3D1&page=1[/url]的讨论中，月影分析了JavaScript中EOS（End of Statement）存在的歧义问题。下面是我的回应。
是否要写“;”呢？
我经过几次反复。最开始是随便，想写就写。
后来都不写。
后来有段时间都写。
现在又都不写。
基本上现在的结果是我最后定型的习惯了。
原因：
1. 程序如果不追求太紧凑（例如要把多个语句写到一行里），分号确实是可以不用的。而且强制自己不用分号，其实是强制自己不要使用紧凑风格。
2. c-style的分号本来就是多余的。为什么这么说？因为明确的EOS只是给编译器的提示而已。而如果漏了分号，编译器会报错。既然它都报错了，显然它知道这里应该有EOS。既然它知道，那么干嘛还要我写？
某人说：【No expert programmers *hate* the situation in which the compiler throws out the program because of a missing semicolon. They ask the very reasonable question "if the compiler knows there should be a semicolon there why the **** doesn't it put it in?"】
所以明确的EOS只是给编译器的hint而已。这在几十年前是一个平衡编译器和用户成本的设计。但是放到现在，就未必了。JS以及许多语言的可选分号或可选EOS，其实就是一种回归。
3. 但是JS的严重问题是，它要兼顾（主要是兼顾从java那里继承下来的c-style的跨行语句习惯）。所以分号自动插入算法导致的实际结果是：EOS可能是分号，也可能是换行。麻烦的是，换行不一定是EOS。换行是否是EOS要看这一行和下一行结合起来。如果加上点括号啊，注释之类的，那到底EOS在哪里就头大了。
4. 所以问题仍然和最初类似，现行的JS的EOS规则，是为编译器（JS解释器）设计的（尽管初衷是为人的方便），而不是为“人”设计的。
5. 一个可供比较的例子是Groovy。它也是允许不写分号的。但是它的规则更好。基本不太会出现很难判断一个换行是否是EOS的例子。参见我的老文章：[url=http://blog.csdn.net/hax/archive/2004/10/17/139490.aspx]Groovy在EOS问题上的痛苦权衡[/url]
6. 本身js的规则也不能说太差，但是最让人反感的，是对括号的处理。也就是月影所举的一系列例子。假如不是因为对于括号处理的[b]愚蠢[/b]设计，js的分号处理完全是可以接受的。
7. 所以如果像我一样，完全不写分号，就必须做到不在语句开始使用“(” 、“[”和其他歧义符号（如“+/-”）。这种情况本来也是比较少的。如对于(function...)的惯例法，可用void function或者new function来替代。
8. 其实出现歧义的情形，后续语句都是一个被丢弃结果的表达式（有例外的情形吗？），所以基本上可以在语句开始加上void运算符来明确，并且消除歧义。当然，更简单的方法是在引起歧义的语句之前（而不是之后）加上“;”。
总之，现在的状况是js的设计失误，如果没有工具支持（比如预处理器来补上“;”），那么从最佳实践的角度出发，就两种选择：
1. 月影的做法
每个语句之后写“;”
优点：作为规范，描述起来比较简单
缺点：老是要写烦人的“;”
陷阱：要记得，function表达式后面也要写“;”
另外，应该尽量避免写出有歧义的跨行语句，因为很难判断是有意为之，还是忘记写“;”。
2. 偶的做法
采用更严格的跨行策略，即只允许在当前行处于未完成状态时跨行（就像你在jsshell中输入代码一样）。
对于可能引起歧义的语句（行首为(、[、+/-等），在句首加上 void 或 “;”。
优点：省略了很多无聊的“;”
养成更良好的跨行代码习惯（适用于所有c-style的语言）
更容易应用工具（比如预处理器可以扫描出所有有问题的行，而对于传统的行尾加分号，工具只能warning，因为无法判断到底是有意跨行，还是忘记写“;”）
缺点：要判断歧义语句，另外在语句首加上void或“;”有点难看
陷阱：暂时没有发现
是否要写“;”呢？
我经过几次反复。最开始是随便，想写就写。
后来都不写。
后来有段时间都写。
现在又都不写。
基本上现在的结果是我最后定型的习惯了。
原因：
1. 程序如果不追求太紧凑（例如要把多个语句写到一行里），分号确实是可以不用的。而且强制自己不用分号，其实是强制自己不要使用紧凑风格。
2. c-style的分号本来就是多余的。为什么这么说？因为明确的EOS只是给编译器的提示而已。而如果漏了分号，编译器会报错。既然它都报错了，显然它知道这里应该有EOS。既然它知道，那么干嘛还要我写？
某人说：【No expert programmers *hate* the situation in which the compiler throws out the program because of a missing semicolon. They ask the very reasonable question "if the compiler knows there should be a semicolon there why the **** doesn't it put it in?"】
所以明确的EOS只是给编译器的hint而已。这在几十年前是一个平衡编译器和用户成本的设计。但是放到现在，就未必了。JS以及许多语言的可选分号或可选EOS，其实就是一种回归。
3. 但是JS的严重问题是，它要兼顾（主要是兼顾从java那里继承下来的c-style的跨行语句习惯）。所以分号自动插入算法导致的实际结果是：EOS可能是分号，也可能是换行。麻烦的是，换行不一定是EOS。换行是否是EOS要看这一行和下一行结合起来。如果加上点括号啊，注释之类的，那到底EOS在哪里就头大了。
4. 所以问题仍然和最初类似，现行的JS的EOS规则，是为编译器（JS解释器）设计的（尽管初衷是为人的方便），而不是为“人”设计的。
5. 一个可供比较的例子是Groovy。它也是允许不写分号的。但是它的规则更好。基本不太会出现很难判断一个换行是否是EOS的例子。参见我的老文章：[url=http://blog.csdn.net/hax/archive/2004/10/17/139490.aspx]Groovy在EOS问题上的痛苦权衡[/url]
6. 本身js的规则也不能说太差，但是最让人反感的，是对括号的处理。也就是月影所举的一系列例子。假如不是因为对于括号处理的[b]愚蠢[/b]设计，js的分号处理完全是可以接受的。
7. 所以如果像我一样，完全不写分号，就必须做到不在语句开始使用“(” 、“[”和其他歧义符号（如“+/-”）。这种情况本来也是比较少的。如对于(function...)的惯例法，可用void function或者new function来替代。
8. 其实出现歧义的情形，后续语句都是一个被丢弃结果的表达式（有例外的情形吗？），所以基本上可以在语句开始加上void运算符来明确，并且消除歧义。当然，更简单的方法是在引起歧义的语句之前（而不是之后）加上“;”。
总之，现在的状况是js的设计失误，如果没有工具支持（比如预处理器来补上“;”），那么从最佳实践的角度出发，就两种选择：
1. 月影的做法
每个语句之后写“;”
优点：作为规范，描述起来比较简单
缺点：老是要写烦人的“;”
陷阱：要记得，function表达式后面也要写“;”
另外，应该尽量避免写出有歧义的跨行语句，因为很难判断是有意为之，还是忘记写“;”。
2. 偶的做法
采用更严格的跨行策略，即只允许在当前行处于未完成状态时跨行（就像你在jsshell中输入代码一样）。
对于可能引起歧义的语句（行首为(、[、+/-等），在句首加上 void 或 “;”。
优点：省略了很多无聊的“;”
养成更良好的跨行代码习惯（适用于所有c-style的语言）
更容易应用工具（比如预处理器可以扫描出所有有问题的行，而对于传统的行尾加分号，工具只能warning，因为无法判断到底是有意跨行，还是忘记写“;”）
缺点：要判断歧义语句，另外在语句首加上void或“;”有点难看
陷阱：暂时没有发现
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
