0

In my attempt to gain a better knowledge of procedural programing, both for practical and academic use I am trying to clarify the effect CONTINUE and BREAK statements have on state.

I have come to understand that GOTO is essentially forbidden as I go with the if you're a good programmer you can find a better way approach. However I also understand at a deeper level that it is to be avoided in procedural programming because it lacks the ability to change state.

This is were I get confused, how is it that CONTINUE, and BREAK can change state?

My initial thought was that because a GOTO is as such:

GOTO A;
LBL A;

No expressions are evaluated and no state is changed. And combined with the form of a CONTINUE:

while (evalFunction(*value) == 1) {
  ..
  if ( bail == 1 ) continue;
  ..
}

Has the ability to change state in the while condition.

However this does not account for BREAK.

Can someone provide some more detail regarding the specifics in procedural programming?

General Grievance
  • 4,555
  • 31
  • 31
  • 45
RyanS
  • 3,964
  • 3
  • 23
  • 37
  • How does "continue" change state in the while condition? "break" sort-of changes state in that the condition won't be tested at all, which is sort-of the same as changing the output of the condition--at least if the condition has side-effects. Otherwise no state will be changed other than the loop terminating. I may be misunderstanding what you're asking, though. – Dave Newton Apr 23 '12 at 19:58
  • I made an edit to the loop, the continue can cause a change in state by calling the function in the condition. I honestly may just be grasping to something that was meant to be more of a 'here's another one of the many reasons to avoid GOTO'. – RyanS Apr 24 '12 at 13:51

1 Answers1

4

I don't know where this "ability to change state" thing comes from.

The highest virtue of code is readability. GOTO is to be avoided because it often makes the code hard to read, and for no other reason. There are in fact cases where code that uses GOTO is easier to read than it would be if GOTO were avoided, and in those cases, GOTO should be used. A good example is the C nested cleanup idiom:

int do_something()
{
   int rv = -1; /* failure */
   Foo *foo = get_a_foo();
   if (!foo) goto out;
   Bar *bar = get_a_bar();
   if (!bar) goto out_foo;

   rv = do_something_with_foo_and_bar(foo, bar);

   release_bar(bar);
out_foo:
   release_foo(foo);
out:
   return rv;
}

This is easier to read than the alternative with nested if statements, because normal control flow is emphasized. (In C++ you would use RAII instead, of course, for even less clutter.)

Similarly, BREAK and CONTINUE can make the code harder to read, and should be avoided when they do; however, they are in nearly every modern language because they often make code easier to read. So they are preferred to complicated if-else constructs inside loops and/or contorting the logic so that the loop exit condition can be tested at the top of the loop.

zwol
  • 135,547
  • 38
  • 252
  • 361
  • Thank you for your response. I am very familiar with the idea of readability and the GOTO statement. However this doesn't really answer anything regarding BREAK and CONTINUE. – RyanS Apr 24 '12 at 13:46
  • Also I care about state because it is fundamental to procedural programming, where the goal is to follow instructions to get the desired change in state. – RyanS Apr 24 '12 at 13:48
  • I suppose you could consider the trajectory of control flow as the evolution of an implicit state variable (the program counter) but I don't think that's a useful thing to do. Anyway, you appear to be trying to find some analytic basis for what is actually a principle of aesthetics, and I don't think *that*'s a useful thing to do, either. I meant it when I said "GOTO is to be avoided *for no other reason* than because it often makes code harder to read" (and conversely, BREAK and CONTINUE should be used *for no other reason* than that they often make the code easier to read). – zwol Apr 24 '12 at 18:04