As Abigail-II correctly points out above, the point of Dijkstra's paper was that programs should be easy to read and follow. At the time the paper was published, many programs were in Fortran and COBOL which did not provide "block-structure" facilities that we're used to today. Rather, code was re-used by setting flag variables and calling various flavors of GOTO.

Let me give a real-life example that I vaguely remember from <mumble> years ago. In Fortran-IV, if you had a piece of code that was used several times (say, calculating a pair of numbers), often you would not structure it as a subroutine, but would arrange for goto's around it. There are probably several reasons for this: in some cases it was (microscopically) faster, and a culture of "the way you do it". So off somewhere in your code you would have:

C      common calculation code
C      Fortran comments have a C in column 1
 1100  if (argin(0) .eq. 0) j=1
       ....
C      the equivalent of a "return"
       goto N
[download]

(By the way, Fortran-IV labels were numeric.) You would then call this code in several places with:

C      do the common calculation
       assign 5500 to N
       goto 1100
 5500  continue
[download]

For those who haven't had the joy of reading stuff like this, an "assigned goto" allowed you to put the label that you want to execute next (in this case, 5500, the statement following the "goto 1100") into a variable, and jump there. That's how you effected a call and return without actually using CALL.

Now imagine "passing an argument" when you're doing this. There's no automatic save and restore, so you have to do that yourself. And if you wanted the calculation to do something slightly differently in one case, you would introduce a global variable, which you would set and use in two different places. Nest this a couple of levels deep, and you have very hard to debug code. Stuff like this was where the term "spaghetti code" originated, I think.

Dijkstra's point was to advocate not writing code like the above, but to use the less-popular call/return mechanisms. The title of the paper was meant to grab people's attention. (I didn't realize the title was Hoare's until I read Abigail's note.) The effect would probably be similar to some well-known computer scientist publishing "While loops considered harmful" today; it would make you sit up and take notice. Unfortunately, many people grabbed on to the title, but missed the main point.

All this, of course, is a roundabout way of saying: write clear and easy-to-understand code, goto or no goto. There's nothing wrong with using a goto (or in Perl, its kin: next, last, redo) as long as it don't obscure how the code works.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.