3 ms·
Why is everyone jumping on this as a negative? Goto isn't inherently evil. Of course in most cases there is a construct that would be a better fit than goto, bu
by jdp 17y ago
Why is everyone jumping on this as a negative? Goto isn't inherently evil. Of course in most cases there is a construct that would be a better fit than goto, but it does have its uses. As far as readability goes, odds are a programmer isn't going to be jumping to a label 300 lines up, its used mostly to break out of nested loops and to simulate stuff like state machines. Check out http://david.tribble.com/text/goto.html http://david.tribble.com/text/goto.html
- pygy 17y agoThey already have a break statement to get out of loops of arbitrary depth. http://www.php.net/manual/en/control-structures.break.php http://www.php.net/manual/en/control-structures.break.php And why, except perhaps for the hack value, would you simulate a state machine in PHP? GOTOs are good when used wisely in certain contexts. I don't see where they could be of any use in the PHP niche (but I'd be glad to hear about such examples). Seasoned PHP coders don't need it. Besides, PHP is mostly a beginner's programming language, who learn by example using code found online. They will be exposed to even worse practices from day one.
- deleted 17y ago[deleted]
- wooby 17y agoIt's not negative in that, people can program using whatever language they want using whatever language constructs they want. But for PHP, which is mostly for web development, I would think using exceptions is a much peer-friendlier way of handling what you'd probably be using goto for in a web app. If you're writing state machines or parsers, PHP probably isn't the way to go anyway. But hey - whatever floats your boat.
- Scriptor 17y agoIt takes a great deal of discipline to not use goto for quick fixes when you feel lazy. Unfortunately, many PHP programmers simply don't have the experience to properly structure code, since PHP is their first actual experience with programming. While major projects like frameworks and well-established CMS's will likely do fine, smaller-scale projects and codebases will suffer.