文章来源:http://carlone0yu.bokee.com/ 

     自从计算机科学一代宗师Dijkstra于1968年发表了著名的文章《Go To Statement Considered Harmful》之后，goto语句就成了过街老鼠，人人喊打。甚至有人开玩笑说："今天你敢用goto，明天老板就让你go home"。

"不要在程序中使用goto"已经成为绝大多数开发者的圣经，但却很少有人认真的思考过，为什么会这样？

goto问题之所以这么臭名昭著，从历史的角度来看，在Dijkstra在ACM发表那篇文章之前，现代软件构造方法还没有出现，goto语句是当时实现流程控制的主要手段。那篇文章发表之后，引发了大量的争论，并最终导致了当代程序员认为理所当然的结构化编程的出现与风靡。

但有趣的地方也正在与此，结构化编程是由goto问题的争论产生的。从时间的顺序上讲，结构化编程语言Pascal，C及现代面向对象语言C++，Java，C#均出现在1968年之后，但为什么这些语言都保留了goto或与goto功能相近的语句？

所以，问题本身并不在于goto。Dijkstra之所以竭力反对goto的原因是因为泛滥的使用goto将会导致软件难以理解和跟踪。所以，我们要反对的是"难以理解和跟踪"的程序，而不是goto语句。

　　　真正的过街老鼠不是goto，而是标号（label），但是过多的使用goto的结果可能还是会给程序带了更多晦涩的地方，毕竟维护和开发很少是同一班人马，个人还是认为，从技术角度来说，goto还是没有问题的，它能给一些天才型的程序员带来更多的自由度，当然也会为他们带来更多的乐趣了，但是，从管理角度上来看，至少前面10年的封杀goto的确为我们的结构化编程带来更好的结果，这个是不容否认的，虽然在统计上，当高级语言编译成为低级语言或者汇编语言的时候，里面的的goto指令或者近似的程序转移指令很多，比例很高，但是实际上，那些对程序员来说可以是透明的，那是在编译后的事情了，对于应用程序员来说，根本不用去考虑到，对于他们来说更加容易阅读的代码才是真正的要点。所以对于我个人来说，goto还是属于那种比较难管理的，对整个工程来说，不利还是大于有利的方面，但是我并不否认goto的作用，想7伤拳一样，虽然伤人先伤己，但是毕竟也是一门威力很大的武功，用得好，还是有可能的，但是对于本人来说还是太难了。