Thread: "goto", is it a taboo?

Yes goto can be used (It is included by ANSI committee in the first place). But it is recommended ONLY when there is no other way to control program flow in C (but there are always other ways to control the flow other than goto). But it does not mean that using goto is always bad.

Al Kelly & Ira Pohl (authors of C by Dissection) advices that its use , if ever, be always forward on to the program and not backwards. Otherwise, you may get bugs that are quite hard to trace

But I don't use goto. It undermines the capabilities of block and structured programming. It meddles up functions and produces lots of spaghetti code too. (Yum!)

> But it does not mean that using goto is always bad.
Sure it does.
It displays a close-minded, scape-goat mentality.

> The indentation would probably go haywire, but consider it properly indented :-)
The miracle of code tags.

The reason I said that is because goto is VERY easy to use, yet very poor form. It's hard to read. If it's a very small example, which is a rare occurance in the code, then no, it's not all that bad. But, if your code relies on goto statements, then I think my comments were appropriate. After all, you're taking the easy way out when there is a better, and more robust way.

1) an example of spaghetti code
2) made complex because of "goto"

If your code is minute, then no.
If your code is very long, and you EVEN only have one small goto statement, then yes.
It's hard to follow code when it has a goto statement.
Simply because, I should be able to goto a certain spot in your code, and see a function call. I simple open the source file that has that function in it, review it, then return to the spot in the code for further reading.

If you have alot of goto statements, or even one in a large source, then I am flipping all over the place through your code.

> And if a programmer says that in his/her code it is really needed,
....then I don't want them behind my products!

The use of goto may be appropiate when breaking out of nested loops:

Not really. When the program gets to the quit: label, it has no idea at which point it jumped from. It therefore difficult to cater for every eventuality with this style. It's also difficult to debug when things go wrong.

Besides, if you have too many nested loops, you'd probably want rethink your code structure anyway.... but that's a topic for another thread!

Well as far as your primary / secondary function "food chain" with your exit function, here's a basic example:

Code:

#include <stdio.h>
#include <time.h>

void wait( int seconds );
int function1( void );
int function2( void );
int callexit( void );

int main( void )
{
        printf("Calling function 1 in 3 seconds...\n");
        wait(3);
        if( function1() == 0 )
        {
                printf("Function 1 executed properly\n");
        }
        else
        {
                printf("Function 1 errored!\nClosing...\n");
                wait(3);
                callexit();
        }
        printf("Calling function 2 in 3 secconds...\n");
        wait(3);
        if( function2() == 1 )
        {
                printf("Function errored!\nClosing...\n");
                wait(3);
                callexit();
        }
        else
        {
                printf("Function 2 executed properly\n");
        }
        return 0;
}

int function1( void )
{
        return 0;
}

int function2( void )
{
        return 1;
}

int callexit( void )
{
        printf("Exit function was called\n");
        return 0;
}

void wait( int seconds ) 
{
    clock_t endtime = clock() + seconds * CLOCKS_PER_SEC;
    while ( ( clock() < endtime ) );
}

I put the time stuff in there so the program wouldn't fly by.
Remove it if you want.

For once Shadow and I agree on one thing: goto is too easy to use but very bad for super duper hyper ultra long codes like 500,000 lines because they reflect a closed-mind and unorganize programming practice.