Today we have a guest editorial from Phil Factor as Steve is on vacation. 

The old GOTO is still there in the SQL standard. Wherever, and whenever,  it is documented it comes with dire warnings of the consequence of its overuse, as if it were a drug. It is so long since I last used it that I’d forgotten about it until I decided to include it in a list of ‘code-smells’ that ought to be detected in the code of database routines.

Actually, some of the warnings against the use of GoTo are due to a misunderstanding. GOTOs became anathema after the publication of  Dijkstra’s paper to the Communications of the ACM under the title of "A Case against the GO TO Statement" . It had been general knowledge before then that ‘the quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce’: However,  he pointed out that the reason was that the use of GOTOs made it harder for the programmer to envisage the progress of the dynamic process. He was at pains to qualify his dislike of GOTOs and the consequence of their use by pointing out that GOTOs were useful for handling error conditions.  He was also emphasising the need for Language designers to make the use of the GOTO unnecessary by providing structured alternatives. Before the article was published, the title was changed to  "The goto statement considered harmful". Others read just the title, and the rest is history.

As with most Code Smells, it is not the use of the software device itself, but the context in which it is used which does the harm.  It is a shame that useful, but subtle, guidance can morph so rapidly into a ‘policy’ that becomes ‘mandatory’. This is why the use of terms like ‘code-smells’ are handy, because they remind those amongst us who are inclined towards control-freakery that they are only indications for code-review, just to check that such things are being used appropriately.  Because there can be smoke without fire, just from good cooking.