When to use Goto and not Do While/Until

120ThingsIn20Years

120ThingsIn20Years

Senior Member
Is it best practice to use a GoTo in this situation?

Or should this be in another Do loop in some form?

I guess the question is, If there is nothing conditional, is a GoTo ok?


Code: 
Main:	
	
	Gosub Init ' populate some variables


	Continue:
'	
		Do until pin3 = 1 
'
'			Add the rest of your Main: code here
'
		Loop
'			
		gosub WaitForRelease 'wait until you let go of the button so you dont skip a mode
		gosub ChangeMode
			
	Goto Continue		


End
 
G

Goeytex

Senior Member
Why wouldn't the goto be ok? Sometimes it is simply a matter of personal preference and/or programming style. The bottom line for me
is does the code work as intended ? And is is readable/understandable?

On the other hand, my brother (the MIT guy, & consummate programmer) is a rigid anti-goto purist. He will at any cost not use a
goto in a program lest another purist see his code and chide and ridicule him.
 
lbenson

lbenson

Senior Member
While from lazyness I would sometimes use a goto as you have done, "best practice" among purists (and I am close) is to use some form of loop ("do ... loop" for your instance).

Here is a link to the source of this way of programming, Edsger Dijkstra's 1968 article, "Go To Statement Considered Harmful": http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

In larger C programs, the only time I would use a goto-type statement is when I am many levels deep in loop-type structures, and an error that can't easily be dealt with is encountered. Then a jump to an error-handling routine may be the only convenient way to handle it, though it is always possible to go back and change each loop or if structure so that you can exit it if an error is met with.
 
Last edited:
D

Dippy

Moderator
Absolutely, in something simple like this example Goto is fine. There is a lot of Goto snobbery.

It's when things get a smidge more complex that you should try and avoid goto as it can be hugely difficult to follow a route.
But it depends where and when it's used. If it's clear to you , and not overused, then Goto it (haha).
I'll leave others to mention structure and spaghetti :)
 
S

srnet

Senior Member
lbenson said:
Here is a link to the source of this way of programming, Edsger Dijkstra's 1968 article, "Go To Statement Considered Harmful"
Click to expand...
"I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code)"

Sounds like he wanted to abolish jumps in machine code also.

Thank heavan such nonsense has been ignored ......
 
hippy

hippy

Technical Support
Staff member
In my opinion it all comes down to "aesthetics" and that's hard to define in absolute terms. It's what makes a program feel right, look right and can be easily and readily understood by the author and also other readers. This is where the science of programming and the rote of coding meets art and, like good art, you may not be able to define it but you'll recognise it when you see it.

In the real world it mostly comes down to whether the program works or not, and an absolutely beautiful looking program is useless if it doesn't do its intended job. There's nothing wrong with a program that works no matter what it looks like or how it was written but that can have an impact on how others perceive it or can understand it and how easy it is to alter it later if that need arises.

We may all start our first DIY project by cutting wood with a bread knife and hammering planks together with rusty nails using a brick and being happy and proud of the result but those who excel will usually have an aspiration towards using the right tools for the job and producing something that others will also stand in awe of. Aspiring to be a good programmer is like aspiring to be an artisan, but everyone is free to have such an aspiration or not.
 
lbenson

lbenson

Senior Member
>Thank heavan such nonsense has been ignored

Perhaps ignored in the sense that the "goto" constructs have not been abolished from many languages, but the gist of the article, that goto statements are harmful in larger programs which may need to be understood and maintained by others, is far from nonsense.
 
hippy

hippy

Technical Support
Staff member
srnet said:
"I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code)"

Sounds like he wanted to abolish jumps in machine code also.

Thank heavan such nonsense has been ignored ......
Click to expand...
If one accepts Dijkstra's arguments that GOTO are harmful in high level languages and his rationale for coming to that conclusion then it does follow that they can be considered similarly harmful in lower level languages in a similar way and should ideally be removed. However he does recognise that, at present, a GOTO is a fundamental entity at the lowest level of program control and thus cannot be removed at that level.

The desirability of removing it entirely is at odds with being able to achieve that is what Dijkstra recognises but that doesn't make noting desirability of removing it a nonsense. If the underlying technology and concepts of computational flow does change that may one day be possible.

As it is now, we can remove GOTO all the way down to Assembly Language, but then some would argue that such an Assembly Language is actually not an Assembly Language. That quickly falls into a prolonged debate over how things are defined and what a particular something is defined as.

Dijkstra's fundamental notion is that a programming world without GOTO is better than one with, ignoring what obstacles there may be in achieving it. Pointing to the obstacles doesn't detract from the dream itself; "world peace" is a still a worthy dream despite that being unlikely any time soon.
 
Last edited:
G

Goeytex

Senior Member
What has happened as a result of Dijkstra's and other's ideas concerning GOTO in large programs, is that some misguided anti-goto sycophants have take it to the extreme, strongly suggesting that any use of "goto" anywhere in any program is laziness or something worse ... which IMO is indeed total nonsense and a form of (un)professional snobbery.

It's similar to the kind of snobbery and nonsense where Assembly Language Programmers scoff at C Programmers for being lazy, while C Programmers do the same to those who program in BASIC.
 
D

Dippy

Moderator
Absolutely, sadly that's life.

I'll just carry on doing it my way and let others carry on the conversation.
As far as I'm concerned Code Snobs can Goto Hell.
Hell:
do {
scoff
} while (selfinserted);

On a serious note there are obvious brain-ache problems with copious and inappropriate use of Goto, but in itself it ain't bad.
But I can see this going round in circles , just like string theory, now so I'll Goto The Kettle.
 
120ThingsIn20Years

120ThingsIn20Years

Senior Member
I love it when all the labels fall off the cans, and when you're a beginner, the only way to check to find out is to open them, and see which ones are full of worms :)

But, If I were to sit in the no goto camp, what would I do instead with that code in the first post?

There is nothing conditional, just a loop.

The only way I could see to make it a Do While/Until, would be to add an line at the end saying

LoopFinished = 1


And then finish with a


Loop Until LoopFinished = 1


What do I use instead?
 
120ThingsIn20Years

120ThingsIn20Years

Senior Member
Hmmm...

I just read this reply to my mode button post in code snippets from hippy and cant figure out if this means
I dont need a conditional While or Until in a Do loop, or is this just pseudo code ?

What is it with me and not being able to find things in the manual.

http://www.picaxeforum.co.uk/showthread.php?19731-Mode-button-select-code-section-to-run-with-a-button-no-interrupt&p=185923#post185923



Code: 
Do  
     Gosub ReadTemperature
     Gosub DisplayTemperature  
     Gosub SendTemperatureVia433MhzTransmitter
Loop
 
B

boriz

Senior Member
I avoid GOTO wherever possible. It's just basic good practice. A conclusion I arrived at completely on my own in the mid 1980's, having never heard of Dijkstra or his ilk.

My personal 'goto rules' are never jump into or out of a loop or subroutine and never use GOTO instead of LOOP.

So I guess I'm a 'misguided anti-goto sycophant snob'.
 
120ThingsIn20Years

120ThingsIn20Years

Senior Member
boriz said:
I avoid GOTO wherever possible. It's just basic good practice. A conclusion I arrived at completely on my own in the mid 1980's, having never heard of Dijkstra or his ilk.

My personal 'goto rules' are never jump into or out of a loop or subroutine and never use GOTO instead of LOOP.

So I guess I'm a 'misguided anti-goto sycophant snob'.
Click to expand...
So rather than jumping into or out of a loop or sub, you would set a variable, and then read that variable in the next gosub?

Man I find this stuff hard to follow :)
 
B

boriz

Senior Member
I have limited experience with 16 or 32 bit ASM, but in the old days when I did most of my ASM programming, 8 bit ASM meant you could only use a conditional branch to move the program counter up to 126 bytes before the branch or 128 bytes after. This makes it impossible to avoid the JMP command (equivalent of GOTO) for all but the smallest of ASM routines.

This in itself makes structuring of ASM programs difficult. But not impossible, with experience.
 
B

boriz

Senior Member
"So rather than jumping into or out of a loop or sub, you would set a variable, and then read that variable in the next gosub?

Man I find this stuff hard to follow"

Me too. What are you talking about?
 
G

Goeytex

Senior Member
"So I guess I'm a 'misguided anti-goto sycophant snob'. "

Naw, That was directed at those that attempt to proselytize new disciples into the no goto religion
while condemning or scoffing at those that may have a different opinion... Haven't seen you or anyone here
you do that .... yet. :)

However, in a past life I had to deal with (manage) dogmatic and egocentric programmers
and I can tell you it can get ugly sometimes.

If you have looked at the code examples I post here, you will see that I seldom use GOTO.
It just irks me when folks get religious and dogmatic about it.
 
B

boriz

Senior Member
When beginning a program from scratch. Often the first thing I type is exactly that.

Code: 
do



loop
Then I fill in the blanks :)
 
B

boriz

Senior Member
Goeytex said:
"So I guess I'm a 'misguided anti-goto sycophant snob'. "

Naw, That was directed at those that attempt to proselytize new disciples into the no goto religion
while condemning or scoffing at those that may have a different opinion... Haven't seen you or anyone here
you do that .... yet. :)

However, in a past life I had to deal with (manage) dogmatic and egocentric programmers
and I can tell you it can get ugly sometimes.

If you have looked at the code examples I post here, you will see that I seldom use GOTO.
It just irks me when folks get religious and dogmatic about it.
Click to expand...
I had to look up the definition of proselytize.

Often people come here as beginners, expecting advice from us old hands. My advice is to avoid GOTO. Sorry if that irks you. (Don't care if it irks Dippy :) )
 
Last edited:
M

MartinM57

Moderator
120ThingsIn20Years said:
That doesn't appear to be in the manual [as in do...loop]
Click to expand...
I was just about to point you at Manual 2 for do...loop to convince you to read more carefully, but it appears not to say that you can have just do...loop ;)

...and nearly every loop in the Manual 2 code examples is of the form:
some_label:
'stuff
goto some_label

Tut, tut....

As above, the starting lines for most of my projects are:

#PICAXE xxxx

do
'put stuff here
loop
 
hippy

hippy

Technical Support
Staff member
MartinM57 said:
...and nearly every loop in the Manual 2 code examples is of the form:
some_label:
'stuff
goto some_label

Tut, tut....
Click to expand...
That's mostly because that is often taught and that's what educators and students expect and most understand when starting programming, and that's our primary market.

The snobbery previously mentioned is perhaps mainly a problem with not accepting that all tools get the job done and in insisting only a specific tool is used or certain tools are not. The argument as to what is better doesn't exclude anything being used IMO.

And I'll make it clear that I'm not accusing you of such snobbery!
 
J

John West

Senior Member
Just my opinion. A couple of analogies:

In the same way as extensive red-lining of a schematic leads to increasing unreadability, too much use of the "GOTO" statement can lead to unreadability in code. More than just a little red-lining indicates that the schematic needs to be properly redrawn. A lot of GOTO's indicates messy, poorly thought-out, hard to follow code. However, just like one or two red-line markings on a computer-generated schematic can save redrawing and reprinting time, GOTO's can serve a useful purpose in code if used sparingly, especially by those of us who write very little code and only small programs that are easily followed.

They're something like bicycle training wheels, only for new programmers. If you can't keep your code upright yet, then use them as needed while you learn the ropes. But experienced bike riders neither want nor need training wheels as they come with distinct disadvantages. Same with GOTO's for programmers. :)
 
Last edited:
lbenson

lbenson

Senior Member
OP asked for "best practice". I don't think that very many programmers who have had to maintain a large program would argue that the use of "goto" represents best practice. Even with small programs, the use of "goto" other in tight loops can easily make the program very difficult for others to follow.

So on this forum we often get programs posted which have many jumps, and the first thing people say is, "I can't tell what you are trying to do". It's like with Dippy and the Pebble breadboard layouts versus a proper schematic--all the information may be there in a Pebble layout, and nicely displayed, but it's too hard to figure out what the circuit is intended to do when compared with a schematic.

This is not to denigrate Pebble--it just doesn't reveal the purpose of a circuit as well as a schematic does--no snobbery involved. Likewise, even a properly functioning program with many gotos is harder to understand than one which is modularly structured.
 
hippy

hippy

Technical Support
Staff member
One thing which makes my eyes gloss over is something like -

wibble:
if b0 = 1 then
goto wobble
else
goto wibble
end if
wobble:
Click to expand...
It can be very difficult to untangle what that does even in a simplistic example. I think it's because your eye and brain follows the first goto and then you have to back track to consider what the else does, if you can remember where you were.

I can understand how it arises, have probably even done it myself, and everyone has to start somewhere. It is also highly likely to be exactly how the author sees the logic of their program and makes perfect sense.

We're really back on the 'art' side of things again - It's not wrong scientifically, but it's not nice artistically, much as there can be horrible grammar constructs, awful poetry and music that really jars. I suppose there's also a maths parallel here in having a very complicated expression versus one which has been reduced to its simplest, or a more recognisable, form.
 
120ThingsIn20Years

120ThingsIn20Years

Senior Member
My desire for best practice is mainly because I'm trying to be as thorough as I can. I figure there's no point learning something with bad habits if you can avoid them.

All this stuff is new to me, so it's just as easy to learn it properly as it is to be a bit slack.

Also, oddly enough, my first project is also an open source project (mainly done by me :) but I understand that's the norm ) so I want the code to be as easy to read by strangers to the project as I can make it.

I've completed each section of code and finished the actual board (not so best practice) except for a few trim pots for in-field adjustment. But the sections of code are pretty much as you might expect a beginners code to look. My aim with this thread was to better understand these loop structures, because as of today, I start writing the final version and knit all the scraps of code together.

And as I said, it may as well be done properly, and in a way that's easy to read.

The code is in scrap form, because I was learning what each component did on the breadboard as I was learning the code, and then adding that new code to the main program.

Once I've done the rewrite, I'll drop a link into this thread, and invite anyone feeling helpful to go over it with a critical eye.
 
120ThingsIn20Years

120ThingsIn20Years

Senior Member
RE:

Code: 
wibble:
if b0 = 1 then
goto wobble
else
goto wibble
end if
wobble:
Hey! did you lift that from my project :)

That does look a little like some of my stuff, and I see what you mean.

It's funny, but if I wrote that I doubt I'd see the problem.
 
120ThingsIn20Years

120ThingsIn20Years

Senior Member
I just noticed on the online manual link that the link to "Symbol" revealed the use of all caps for variable names ie.

Symbol THIS_VARIABLE = b23

Is this also considered best practice?

This might be a little controversial, but can someone upload a .bas file that generally conforms to best practice so I can see what else I've missed before I do my final re-write.

So far my re-write looks like this...

Code: 
Start0

    Do

    Loop

End

:)
 
lbenson

lbenson

Senior Member
I personally don't think there is an agreed-upon "best practice" for capitalization in a basic program, although some, like westaust55, like to capitalize all PICAXE basic keywords ("IF", "DO", "HIGH", "LOW", etc.). That's probably as close to a standard as you will find, though most don't follow it, myself included. The color scheme provided in the Programming Editor helps to sort out the variables from the keywords--but that won't help if you're publishing code in plain text.
 
B

boriz

Senior Member
I can't show you anything I have written showing all best practices. I have probably never written such a program. (If you can't do, teach!)

The point is, no program is perfect. 100 different programmers can create 100 different programs that will do the same thing. Who's to say which is best?

The fastest? The shortest? The one that uses least memory? The most elegant? The easiest to follow for another programmer? The quickest to produce? The most user friendly? The most colourful? The loudest? Etc...

Basically, if it works, keep it.

If your definition of 'works' includes stuff like making later edits/updates easy, (or forum code questions), then it may require a little more forethought and dare I say it, 'structured programming'.

Hey. I'm not here to kill your buzz. Each to there own. Man.

(Still. Try not to use GOTO. It's a sin.)
 
You must log in or register to reply here.
Top