cr0sh
Member
I especially liked the opening paragraph of that article:
"Developers, Software Engineers, and Programmers are logical, rational, reasonable people right? Sure they are…until you disagree with something they believe in. Then they can become the most enflamed, outraged, foaming-at-the-mouth, intolerant, lunatics you've ever had the pleasure of meeting."
Seems that is exactly what happened in this thread. I for one learned something. Arguing with Software Engineers is just like arguing religion. Fortunately, in my working life, I was always in a position where I managed software engineers, and was in a position to fire them.![]()
Mike, throughout this thread, I have never said you should never use goto. Not even K&R said that. As a software developer, though, I have found when to pay attention to certain development patterns; when to use what, and where. In my opinion, goto is a tool that should be used sparingly, and with adequate justification. If the application calls for extremely high processing speed, and goto is the only way to achieve it, then you can argue for the use. I have learned, though, you shouldn't always assume this is the case; instead, you write up benchmarking tools to gain a quantitative analysis of the issue, for all possibilities under examination.
I for one, am not arguing with you; I have felt this discussion overall to be quite informative and educational; for instance, thru this thread I learned of misterT's interesting solution, and 3v0's updates to it; I found that to be a highly interesting solution (it has an OOP feel to it). Even your contributions with the goto statement was an interesting look at a different solution to a problem. I am always interested in learning new things, and I found this thread to be abundant with such opportunities.
At every opportunity in this thread, I have tried my best to be fair, to look at what was presented and weigh the possibilities. I still stand by my original opinion: There are times when you should/need/must use goto; those times should be few and far between. Know when to use the best tool for the job. That's all I've tried to convey.
Finally, I sincerely hope you aren't suggesting that you'd fire a person just because they have a difference of opinion? Its one thing if the project demands something that only goto can provide, and the programmer dogmatically sticks to their guns instead of doing per the specification, without demonstrating via benchmarking or other means their justification. If they can justify it, then you should have adequate justification with similar backup to argue your position. Firing a person otherwise (on this point alone) seems extreme, IMHO.