In 1968, Edsger Dijkstra published the paper that put him on the map permanently in the minds of most of the software development community. While he made a number of very important contributions to computer science during his lifetime; I believe that “Go To Statement Considered Harmful” has spawned what has become perhaps the most enduring and pervasive religion in the annals of computing history. In my two-plus decades in the industry, I’ve seen only one coding standard which did not entirely prohibit the presence of the goto statement; and even that one that allowed it in one limited circumstance.
It is interesting to note that Dijkstra was not the first among the giants of a then nascent computer science to express a distaste for the goto; but his little two page note in “Communications of the ACM” was indisputably the most influential of these expressions. I have read, from a source that I can no longer recall, that some time later Dijkstra lamented how over-zealously his words had been applied.
Goto-less purists have also instituted rules against break and continue ( in C parlance )within loops, arguing that these are just alternative forms of goto. I find this argument to be ridiculous. These constructs can have an adverse impact on readability, but one could make the same argument for virtually any construct of the C language when used in inappropriate circumstances. In one organization where I worked, this argument was used to justify an ancient prohibition against the use of these statements. A bit of digging uncovered that the original reason for the prohibition (about 15 years earlier) was because of limitations of the debugging tools of the day.
I am not arguing for the wholesale acceptance of goto as a replacement for structured program-flow mechanisms; but I believe that senior developers should recognize that the occasional forward goto can be a useful mechanisms when applied judiciously and with appropriate comments. It can actually improve program efficiency, maintainability, and even analyzability. Some programming practices (such as the do-once [or do-while(FALSE)] loop) exist simply to circumvent the prohibition, substituting the break for the goto end. This can quite useful to avoid deep nesting of complex conditionals; but it is really just a confusing substitute for one appropriate use of a goto. [Personally, I’d like to see a more syntactically appropriate equivalent to the do-once built into the C language; providing just one less valid reason to even wish for the goto.] In short, I believe the goto should be avoided, not prohibited.
While Mr. Dijkstra’s two-page article has influenced the entire industry, a forty page article published in ACM Computing Surveys by Donald Knuth in 1974, “Structured Programming with go to Statements” is hardly even remembered. Mr. Knuth indicates that the article was effectively a collaboration of 30 – 40 authors, with Mr. Dijkstra being among them. The article rebuts the total abolition of goto, providing both examples as well as counter-examples for acceptable usage. The article wisely concedes that programmers should be trained in the absence of gotos so that more structured ways of thinking about program design are formed.
I would be inclined to strongly agree with Steve McConnell, Author of Code Complete, who writes “Good programming doesn’t mean eliminating gotos. Methodical decomposition, refinement, and selection of control structures automatically leads to goto-free programs in most cases. gotolessness is not the aim, but the outcome, and putting the focus on no gotos isn’t helpful.”
|
Max is a father, a husband, and a man of many interests. He is also a consulting software architect with over 3 decades experience in the design and implementation of complex software. View his Linked-In profile at http://www.linkedin.com/pro/swarchitect |
subscribe
Comments