Why is goto a bad programming practice?

[jamesbond]

I just thought I'd pop in with a comment about how to never use a goto in your code. I first developed this as a counter argument for the usual arguments made against the goto. It is something that could be automated so a person need not do it, but I will express it as though a person does the process.

Start with your code complete with GOTOs.

Make an array full of random 32 bit integers with no repeated values and one entry for each line of source.

Each like of code gets its random number followed by a ":" added at its start.

Each line that is not a GOTO gets something like "QQQ=123; break;" added on its end, where QQQ is a variable that does not exist in the input code and 123 is the number for the next line.

The GOTO lines get replace with assignments to QQQ.

The last line is a special case because it must exit.

Now you can sort the lines to put them into some other order if you choose and then wrap it all in a while (1) and switch (QQQ) and presto, you have code with not a single goto in it.

I made this argument to point out that it is the thinking of the programmer and not the "GOTO" that really matters. If you set out to make code that is easy to follow, you can use the goto with caution. If you set out to make a mess, not having GOTOs wont save the poor guy who has to maintain it.

Sounds like a recipe for an obfuscator

[blaarghalltheusernamesare]

that idea is even worse than goto.

[Moose On The Loose]

that idea is even worse than goto.

If you are referring to the conversion to code without "goto", then yes, it wost certainly is worse than code with "goto". That is the whole point of it. It shows some important points:

The goto is not the problem in the confusing code.

In any nontrivial language, you can create the same effect as the goto.

The assignment operation is as dangerous as the goto.

[Bruce B]

I was thinking if you are deeply nested in loops and you want a way to get
the hell out, goto might be a good expedient.

?????????????????????????????????????????????????????

[Flash]

How about programming in Forth, which I believe has no equivalent to goto. Does that mean Forth is easier to troubleshoot and maintain?

[Bruce B]

How about programming in Forth, which I believe has no
equivalent to goto. Does that mean Forth is easier to troubleshoot and
maintain?

Some thoughts, with an example.

Code: Select all

for i in `cat $1` ; do
	printf "\x$i"
done

It is tight efficient code. Well formatted. It does what it is intended to do,
no more or less.

However, it doesn't have any comments. This absence would cause the
next programmer to wonder and figure. What for? Why? How does it fit?

For my own purposes, I don't need comments.

When sharing code and working with others, especially when you expect
others to work with your code in the future, not explaining your code is
intentional as it is explaining.

~

[Bruce B]

Compare same code with comments
for purpose of illustration.

Code: Select all

#!/bin/bash

# The purpose of the for loop below
# is to convert a hex dump file to text.

# infile format should be like this:
# 48 65 78 7c 20 43 68 61 72 20 20 48

for i in `cat $1` ; do
	printf "\x$i"
done

One can read the English, one can read the code and it all
works just fine for others working with the code.

~

[rcrsn51]

I was thinking if you are deeply nested in loops and you want a way to get the hell out, goto might be a good expedient.

That's true. But the better solution is to restructure the code so the deep nesting is not required.

[Moose On The Loose]

I was thinking if you are deeply nested in loops and you want a way to get the hell out, goto might be a good expedient.

That's true. But the better solution is to restructure the code so the deep nesting is not required.

Often, a restructuring of the code to make it take less depth would make it even harder to figure out later. If the problem being addressed looks like a 3D object, having a loop for each dimension can be a lot simpler to understand than having just one loop. In the one loop case, you would need to work out indexing based on the loop counter or some other way.

Sometimes it is a lot easier to understand code if the "if" statements are nested rather than anding conditions.

Code: Select all

if AlarmClock then
  if WorkDay then
    goto work
  else
    turn off AlarmClock

[nooby]

I should not write here

But I did Assembler code and Pascal and C and C++ and such way back when such things where the in thing to do for us that have newly been able to buy a computer that could do such.

I did Forth to. But I was incredibly lousy at it.

But the cool thing is that already then did they warn about this GoTo as not a good practice. One of the few things that I remember

[ViejoVizcacha]

I personally find 2 no-nos for GoTos:
1-Is like using drop-pants; if you use them(GoTo[s]), you will be criticized. You choose.
2-In consideration to other programmers, is better if you write modular subroutines (small, enclosed functions, no goto[s]) since modules are easier to understand and maintain. Otherwise, if I was writing a program that only I was going to see it, I used gotos as needed. For instance, in programs of more than 1,000 lines and say, 100 gotos, it becomes problematic following and matching labels and gotos in the mind.

[droope]

Wouldn't it be fun to create software that has no functions, but only gotos?

[mahaju]

Wouldn't it be fun to create software that has no functions, but only gotos?

It will probably be a database with all possible questions and all the possible solutions
The programmer will then just goto the right answer

[Moose On The Loose]

Wouldn't it be fun to create software that has no functions, but only gotos?

In a macro assembler, it is not hard to make large chunks of code with no function calls and gotos for the path through it. If you are coding a parser to parse algebraic expressions, that is the most efficient way to do it. You will discover that many parsers logically work like the goto based code but use a loop and a switch() statement to implement what they are doing. It is very like the example of how to turn goto code into code without gotos shown above..

[potong]

The answer to "Why is goto a bad programming practice?" is ...

As a trainee COBOL programmer I was told GOTO's use 3 machine instructions PERFORM's use four.

From which I derived that GOTO's were quicker (if a little fiddly).

However, every programmers manual I was handed derided GOTO's as being:

• 1. Open to logic errors
  2. Made programs hard to read

For these reasons PERFORM's were the preferred way of coding loops.
if GOTO's must be used, they should jump forward, never backwards i.e. GOTO-EXIT.

I question hardened programmers (both contract and system staff) about this and came to the conclusion.

• Use PERFORM's in production code that is likely to be maintained.
  Use GOTO's for performance i.e. program libraries.

Years later there was a very slow overnight web logging Perl program.
By replacing calls to certain key functions with their statements and goto's (and in one or two circumstances even hardcoding some loops), the speed gains were impressive (but I wouldn't have wanted to maintain it!).

HTH

Potong

p.s. Then there was the Cobol ALTER verb ....

[Moose On The Loose]

9snipped)
Use GOTO's for performance i.e. program libraries.[/list]Years later there was a very slow overnight web logging Perl program.
By replacing calls to certain key functions with their statements and goto's (and in one or two circumstances even hardcoding some loops), the speed gains were impressive (but I wouldn't have wanted to maintain it!).

HTH

Potong

p.s. Then there was the Cobol ALTER verb ....

The gcc compiler does a very nice job of inlining functions if you use both the inline and combine features. The resulting increase in speed can be 2:1 without a change to the source. Once you have your program working with a normal make, you can use a script to recompile the whole thing in one big combined compile.

[RetroTechGuy]

I have been thinking about this for some time but can't find any plausible answer. What is the reason, exactly, that a goto statement is considered harmful? Why is it bad programming practice? I have been trained to write programs without goto and also avoid using it, but what is the thing actually hat makes it bad programming anyway? The only reason I have found it to be considered bad programming practice is due to a paper by Djikstra, but I haven't been able to get the paper. Does anyone have a convincing answer?

It's twofold.

1) Mostly because programmers hate anything that is ill defined. If they can't assign an array, then they aren't happy.

Of course, they are wrong when they imply or state that it is an incorrect method. It is really very useful.

2) As Jamesbond notes, many produce spaghetti code, which is a real pain to debug.

If you're going to use "goto", use it clearly, without goofy nesting. I often use it as an indefinite length "do" loop tag, nesting the "do loop" pieces so the loop is clear. This allows me to process an entire arbitrary length file, without having to over-specify the do loop index, and without worrying that I underspecified the index...

e.g. (well, that should all be indented correctly for Fortran, but):

Code: Select all

10 read(*,'(a)',end=100)text_string
text_string(12:14) = 'new'
i = len_trim(text_string)
write(*,'(a)')text_string(1:i)
goto 10
100 end

Which, of course, reads each line and replaces the original text in characters 12 to 14, with "new". It doesn't care if the file is 10 lines, or 1,000,000 lines.

An approximate equivalent, would be:

Code: Select all

Do j=1,10000000000000
read(*,'(a)',end=100)text_string
text_string(12:14) = 'new'
i = len_trim(text_string)
write(*,'(a)')text_string(1:i)
end do
100 end

Since I don't know how many lines might come in, I need to over-specify the index.

[mahaju]

It seems that goto is considered harmful only if I use it to create elaborate loops and sub routine calls such as for, while loops and functions. In fact, I have read that after Djikstra published his paper, some other prominent people working in the field of computers at that time published their own counter arguments to Djikstra, which made Djikstra publish further counterarguments to those counterarguments. So it seems, the practice of considering goto a bad habit was itself debatable. So goto can lead to spaghetti code. Considering this true, what if I just use goto with some if then conditions to skip just few lines or blocks of code, never nest goto, never use goto to enter or leave a block and avoid using goto to move back in a program. Would this be a bad practice then?

I always thought it had something to do with the design of compilers which makes goto a bad practice, but maybe I was wrong

[RetroTechGuy]

It seems that goto is considered harmful only if I use it to create elaborate loops and sub routine calls such as for, while loops and functions.

If we were to eliminate or ban every program function or tool that was misused, that resulted in spaghetti code, or was otherwise unintelligible, we would be left with nothing (or perhaps only the Fortran command "end").

See for example, C:

http://www.ioccc.org/main.html

http://en.wikipedia.org/wiki/Internatio ... de_Contest

[mahaju]

my opinions were with keeping the academic sector in mind
I mean wherever the basics of C and C++ are taught, it is always emphasized that goto is a bad programming practice and it's use should be avoided in favour of other programming structures. That's not a bad idea in my opinion but people seem to have no idea why goto is bad in the first place. I mean it's not like we need to use goto's to create subroutines or basic loops any more, so skipping a few lines using conditional statements and goto seems to make it actually easier to program