abscon
2015-05-06 11:46:27 +08:00
打个比方，你要学画画，老师会对你说，画画的时候尽量不用紫色，多使用红色吗？用什么颜色显然取决于被画的东西和你要表达的情感。
再打个比方，你要学中国象棋，老师会对你说，将军的时候尽量用铁门栓，少用马后炮吗？用什么杀招显然取决于棋盘上具体的形势。
语言提供的这些for啊break啊continue啊if啊else啊goto啊什么的(我假设你学的是类C语言），你可以理解成调色板上不同的颜色。
你可以想一下，既然书里面表达了自己的偏好（尽量不用break），那么语言的发明者为何不干脆取消掉break呢？既然留着它，说明某些场合下还是可以合理使用break的。那么就应该说清楚：什么时候应该使用break？什么时候不应该使用break，使用和不使用都有何利弊？而不是在写循环之前就确立一个规则：尽量不用break。这本书这么简单粗暴地教你，引起了你的怀疑和不理解，所以在v2ex上发了这个帖子，这是很合理的怀疑。
而且，对于使用break跳出循环的程序，总可以添加控制变量达到逻辑等价的效果，从而消除break。根据你看到的书里的示范，“尽量不用break”对于你来说其实就是“别用break”。
我写一个循环之前，自己都不知道要用到些什么关键字。是用while还是for？要不要用break,continue和goto？这些我统统都不知道，没有先验的规则。先想明白你此时此刻代码要做的事情的整个流程，就像下棋一样，以一定的原则（比如清晰/高效）反复调整代码，最后事情就这样成了:)——关注点应该在于某一个具体的循环怎么表达才优美简洁效率高，而不是多使用某某表达方式。
------------------------------
上面说的是这本书在教学方式上的错误。接下来说一下它在内容方面的错误。
它之所以提倡别用break，是因为它：
1. 提倡“结构化编程”
2. 认为使用break（还有return，goto）打破了“结构化编程”的“一进一出”原则
在这里我不想说1.和2.都是不对的，我只想说：学术上的争论就留给学者去发论文吧。程序员写程序时不要为了学者制订的一个不确定能带来什么收益的规章制度而扭曲自己的思维。 除非该学者告诉你照他说的做可以形式化验证你程序的正确性。