C# and Goto Loop Haters

[denverpotsmoker]

Hey!

 

I'm busy learning C# and it's pretty cool. I've programmed plugins in XLISP, so learning C# hasn't been too bad. I just learn as I go.

 

Anyway, why all the hate on using Goto to make loops?

 

I mean, wasn't Dijkstra really saying that the programmers in the 1960s were so awful that they needed to use FOR-NEXT loops or they'd mess it all up?

 

I mean, I'm definitely for assemblers that won't make (or test) code that will lock up a machine, but I don't think forcing people to not use Goto to make their own loops and code jumps is the answer.

 

What's your opinion?

 

http://www.codeproject.com/Articles/36899/Why-goto-Still-Exists-in-C

http://stackoverflow.com/questions/6545720/does-anyone-still-use-goto-in-c-sharp-and-if-so-why

[BoltBait]

Why the hate?

 

I will just say that using GOTO to control program flow works fine.

 

The major problem is that using GOTO instead of other structures (DO/WHILE, REPEAT/UNTIL, FOR/NEXT, etc.) makes your code MUCH harder to follow when trying to understand and/or debug the code.

[MJW]

There are some who have an almost religious hatred for GOTOs. I'm not one of them. However, I can't see much excuse for using them to implement loops when there's a wide choice of loop constructs available. The problem with loops using GOTOs is that it hides the program's structure.

 

Consider:

for (x = 0; x < xMax; x++)
{
    count++;
    
    do
    {
        sum2 += x * x;
        if (g(x) > gMax)
            sum += x;
    }
    while (f(x) < fMax);
}

Compare that to:

    x = 0;
xLoop:
    if (x < xMax)
        goto xLoopDone;

    count++;

fLoop:
    sum2 += x * x;
    if (g(x) <= gMax)
        goto xLoop;
    sum += x;
    if (f(x) < fMax)
        goto fLoop;
    else
        goto xLoop;
 
xLoopDone: ;

(I can't guarantee I didn't make any mistakes in translating the original code to the GOTO version, since I didn't actually test it.)

 

Dijkstra's objection to GOTOs was that they tend to lead to poorly organized code, which is error-prone and very difficult to maintain. Anyone who's had to take over someone else's FORTRAN spaghetti code knows that there's a lot of truth to that. One problem with GOTOs is that they can be a loop, an exit from a loop, a jump around conditionally executed code, or a change in the execution path. Often the only way to tell is to painstakingly trace through a large chunk of code. I've seen plenty of awful GOTO-less code, but at least code with restricted use of GOTOs is hierarchical, which provides some level of organization -- something often entirely missing from GOTO-centric programs.

 

EDIT: Even after I attempted to patch it up, my example is still completely messed up and also makes no sense. I'm not sure that matters much, since I was just trying to show how using standard loops shows the program structure clearly, while GOTO-based loops don't. I may try to fix it later.

Edited September 25, 2015 by MJW

[denverpotsmoker]

Yeah, personally I wish goto was stronger and could include going to a separate text file

and position in that file.

 if (g=100) {goto code-base01.txt line-021;}

...probably needs some other upgrades too.

 

I hate having to put all code in one document, that's WAY too old-school for me. Here's

the Kevin Flynn way:

if (g=100) {goto LINE-35013}

 

...that's some funny stuff...

  :game: :game: :game: :game: :game:

   :game: :game: :game: :game: :game:

      :game: :game: :game: :game:

        :game: :game: :game: :game:

          :game: :game: :game:

            :game: :game:

              :game: :game:

                 :game:  #

                 :game:    #

                         #

                             #

                            

[TechnoRobbo]

The classic answer is that GOTO has no WHEREFROM

[MJW]

You don't have to put all the methods for a class into one file; you can use partial classes. If you want to put a single method into multiple files, your method is too darned long! Refactor! The idea of GOTO jumps across file boundaries is, in my opinion, horrible. Why, why, why?

Edited September 25, 2015 by MJW

[Rick Brewster]

GOTO results in code that is harder to reason about and that more easily becomes completely intractable.

 

The problem is only moderate for brand new code. It becomes ridiculous when the code has been maintained for awhile and has bug fix bandaids all over it. "I'll just fix this by adding a GOTO over here ..." x1000

 

Think of it like this: having a can of Coke isn't that bad. It's yummy! But if you drink 10 of them a day for 10 years, you will be very much the opposite of healthy.

 

Basically, what MJW said.

[denverpotsmoker]

The classic answer is that GOTO has no WHEREFROM

Yeah, that would be a good one to add to Goto.

 

Also, how about GOTO <variable>...

as in:

A = X:\User\Program\Pallete Engine\RGB Engine LINE-041

B = ?

 

GOTO A?

 

 

....ahhhhh, that's it for me on this topic bros. looks like you guys win again. true pain here.        :foaf:   

[MJW]

Also, how about GOTO <variable>...

 

 

Fortran used to (and perhaps still does) have an assigned GOTO statement. I was quite fond of it. Calling functions through a pointer in C/C++ or a delegate in C# can in many situations achieve a similar result.

Edited September 26, 2015 by MJW

[denverpotsmoker]

Yeah, MS-DOS BATCH can use variables for its goto statement, unfortunately, my brain shuts

down whenever I get to making a batch with variables with "% %" around them. I always thought

the BASIC $tring variable was pretty lame tho.

 

I might also offer up for argument the fact that: For-Next Should Have Been Considered Dangerous...

as its used to replace goto loops a lot.

 

Back in the day when things like (QBasic's) gosub and for-next and do while loops were being introduced to

the "general public" through their new home computers (early 1980s), people were taught to use

FOR-NEXT loops as time delays.

 

The idea was that (due to the speed of the processor), counting so many times using FOR-NEXT

would equal so many seconds. The problem was that as processors got faster, the length of time the

programmer's FOR-NEXT loop took grew to nothing, and thus parts of their programs became no longer

functional without a CPU emulation program.

 

Oh well, I guess I'll never get to play that "Hong Kong Hustle" type-in game...

[MJW]

 

I might also offer up for argument the fact that: For-Next Should Have Been Considered Dangerous... as its used to replace goto loops a lot.

 

I don't think that follows. The problem with GOTO-based loops isn't that they necessarily do something bad; it's that they hide the logical structure because the looped section isn't syntactically differentiated from the surrounding code. There are no grouping symbols (like brackets) or reserved begin-end words (like For and Next) around the repeated code. Also, For-Next enforces a hierarchical structure. Loops are always nested. They can't overlap as they can with GOTO loops. If the mere fact that a loop structure can replace a GOTO loop makes it suspect, all loop structures would be suspect, because all loops can be implemented as GOTO loops.

Edited September 27, 2015 by MJW

[denverpotsmoker]

Well, grouping symbols are probably better done using structural commenting (IMO).

//=====================LOOP01: start

 

//=====================LOOP01: end

 

The hierarchal structure could be good, but what if someone needed to "figure 8" through code?

 

All I'm saying is that the "computing world" lost a whole generation of programs due to that FOR-NEXT (wait)

code from the early 1980s. Who's to say if that was a bad thing or not as those programs couldn't do much,

but it is a real chin scratcher. Now, that code could have been suggested in goto form...but it was not.

Coincidence?

 

I read an interesting "web opinion" page in the mid-2000s that was titled something like "Real-Time Programming",

that really said some stuff that made sense. The person was arguing that code should have more system time checks

in it, instead of just relying on processor speed.

 

You know, stuff like:

//==============================timer loop (start)

delay = 10; //seconds

TIME = DateTime.Now.TimeofDay;

if (WAIT < TIME + delay) then <loop>;

//==============================timer loop (end)

 

In this way, the program always will take 10 seconds to do whatever, even with hardware upgrades.

 

[ArgusMagnus]

I can't really follow you. How would implementing wait loops with gotos instead of for-next have have resulted in processor speed independent waiting?

 

Nowadays, no one would implement waiting with loops, but usually there are better options than implementing this yourself with DateTime.Now, etc. such as Thread.Sleep or Timers (such as System.Timers.Timer)

[denverpotsmoker]

@ArgusMagnus

That's what I was saying.

 

They could have easily suggested wait loops using gotos, but they (the magazine/book code writers) kept telling everyone to use FOR-NEXT loops.

 

FOR-NEXT Loops were new then, and (I guess) it just made it so easy to do (as compared to making a wait loop using goto), that I guess everyone just jumped on that bandwagon and used FOR-NEXT for those doomed wait modules...to their own program's eventual deprecation.

 

I think it is sad, and probably the reason I prefer to make my own looping constructs to this day.

[TechnoRobbo]

It's been a long time since I programmed in Assembly Language but I believe the FOR-NEXT has it's origins in the JZ, JNZ, JE and JNE instructions that use very little processing clock cycles to accomplish conditional looping, and FOR-NEXT is easy for the Assembler (Compiler) to translate to those conditional jumps. Either that or it's a conspiracy by "The Man" to brainwash us into programming all the same way like pathetic sheep following the herd.

[Ego Eram Reputo]

68000 Assembly: BNE, JMP and JSR. JSR was expensive - hording a massive 14 clock cycles! Ah, that takes me back....

[TechnoRobbo]

68000? Mac Programmer? In intel JZ used to be around 3 cycles.

[Ego Eram Reputo]

68000 was Atari ST

JSR was expensive because it stored the return address. A true gosub.

[Red ochre]

Commodore64 machine language uses JSR too.
3 bytes, 6 cycles.
(I've still got the book & the machine - it may come in useful one day!).

[TechnoRobbo]

Commodore64 machine language uses JSR too

 

I used to compile 6502 by hand - I was too cheap to buy the Assembler.

[BoltBait]

I never used 6502. I owned a TRS-80 Model I and learned Z80 assembler as my second language after BASIC.

[TechnoRobbo]

I never used 6502. I owned a TRS-80 Model I and learned Z80 assembler as my second language after BASIC.

I actually started on a CoCo's 6809E - Bill Barden's books and MASM

[denverpotsmoker]

If you look at the historical context of Dijikstra's paper, I think he might have been right.

Fact 01: Programmers often had to time-share computers, meaning that one glitch or non-ending loop could cost thousands of dollars

              AND a loss of allocated time on a computer.

Fact 02: Many financial institutions also time-shared mainframes, so one non-ending loop could cost hundreds of thousands of dollars.

Fact 03: Being in such a "time-sensitive" coding environment, if a bad goto needed to be found, many programmers would have to work

              on debugging it. Thus, sloppy/unformatted/undocumented code could cost a ton of money.

 

Those would be very "harmful" things back then.

[MJW]

I don't know what your programming background is, but most professional programmers have to, at one time at another, support code written by others. If you've ever tried to figure out and fix someone else's spaghetti code you would probably realize that disorganized code is a very harmful thing today, as it was in the past.

[denverpotsmoker]

Yeah, back then structural commenting was, like, impossible and stuff.

I'm guessing getting a print out of your code was a pain, though probably possible.

 

My mother said one of the biggest problems with coders back then was them misorganizing their (code) punch cards.

The operators would then have to get them to remember how to put the cards in order over the phone.

 

Yeah, disorganization is very bad for computers. Today we have folders and files to help organization.

 

I never got much into assembly programming. I dunno why.

 

Oh yeah, pretty sure using goto's would compile quicker due less replacement coding in compilation. That's

pretty significant.