Comment Re:Why, God, why???? (Score 4, Interesting) 176
I felt the same way until I watched Douglas Crockford's videos on javascript. If you hate javascript, you're doing it wrong. I now prefer it to the other languages being discussed here.
I felt the same way until I watched Douglas Crockford's videos on javascript. If you hate javascript, you're doing it wrong. I now prefer it to the other languages being discussed here.
But I might have missed some. There is not much difference between "return 0;" and "ret=0; goto exit_function;". Both are unconditional jumps there is no rational reason why one should be "considered harmful" and the other not.
If there are resource allocations, or at any time in the future resource allocations may be added, there is a huge difference between these two in terms of maintainability. A single point of return makes it trivial to ensure that all allocations are properly freed.
There are two types of functions containing multiple points of return: those with bugs, and those that will have bugs. In a large project, with many engineers, you can reliably find bugs simply by searching for functions with multiple return statements. They're practically always buggy.
err... Word docs crud up with invisible mark-up, as well. It isn't relevant that the underlying mechanism is different. With no "reveal" option, it can be infuriating trying to find and delete the invisible things so the formatting will be correct.
The one application of "goto" that I swear by is for cleaning up allocations on failure when coding in C.
Maintaining a huge library of legacy C code, one of the most common bugs we see is leaks due to people using multiple "return" statements and failing to clean up allocations. You can fairly reliably pick such a function at random and find a memory leak: people always get it wrong.
"goto cleanup;" however, is hard to mess up.
I've seen any number of clever tricks to avoid the "goto". Using "break" statements in a do {} while (0) loop, for example. All of them merely obfuscate the code, and make it more likely for bugs to appear.
No amount of careful planning will ever replace dumb luck.