120ThingsIn20Years
Senior Member
OK.
I'll just do it and hopefully I don't do anything too wacky or too hard to change later
I'll just do it and hopefully I don't do anything too wacky or too hard to change later
When to use Goto and not Do While/Until
- Thread starter 120ThingsIn20Years
- Start date
I spent 29 years in Information Systems as a programmer/analyst, project leader, etc using COBOL, VB6, IBM DB2, SQL Server, HTML, javascript...
COBOL had some terrible constructs like "go to depending on...", etc. This type of "spaghetti code" was terrible to understand and maintain - even by the individual that wrote it. When "structured programming" became the accepted standard in the mainframe world, it made program maintenance much easier.
That's not to say that you couldn't write a crummy program using structured code, but eliminating gotos made it harder to write sloppy code.
Object oriented programming was the next evolutionary step and still widely incorporated in development languages.
I strongly encouraged my employees to use structured code and avoid gotos. Some were stubborn but most eventually discovered the benefits - especially when they had to maintain programs written by someone else and modified by several others...
My two cents worth
COBOL had some terrible constructs like "go to depending on...", etc. This type of "spaghetti code" was terrible to understand and maintain - even by the individual that wrote it. When "structured programming" became the accepted standard in the mainframe world, it made program maintenance much easier.
That's not to say that you couldn't write a crummy program using structured code, but eliminating gotos made it harder to write sloppy code.
Object oriented programming was the next evolutionary step and still widely incorporated in development languages.
I strongly encouraged my employees to use structured code and avoid gotos. Some were stubborn but most eventually discovered the benefits - especially when they had to maintain programs written by someone else and modified by several others...
My two cents worth
Last edited:
120ThingsIn20Years
Senior Member
At least there's not a lot of Mac users in the programming world
hippy
Ex-Staff (retired)
Given there are nearly 400,000 apps in the Apple App Store and it requires a Mac to develop those ...At least there's not a lot of Mac users in the programming world
120ThingsIn20Years
Senior Member
I know, I was just adding to the nonsense
inglewoodpete
Senior Member
Have you compared VB.Net to VC.Net? The curly brackets are about the only difference! In 10 years they will be the same. What will we argue about then?
The correct use of 'white spaces' in code ?
120ThingsIn20Years
Senior Member
Well, that is the kind of thing I need.
120ThingsIn20Years
Senior Member
This is what I've been doing so far.
Try to ignore the GoTo's
Try to ignore the GoTo's
Code:
CheckForLeverPress:
If PinC.2 = 1 then
Pause 50
GoSub Feed
Endif
GoTo CheckForLeverPress
goto start1inglewoodpete
Senior Member
Time you were in bed, 120
120ThingsIn20Years
Senior Member
Sleep is for the weakTime you were in bed, 120
Here we go then, some white space;
OK ?
Use with care, it may affect your programs.
120ThingsIn20Years
Senior Member
Or did you mean I should just take the laptop and lie down for a bit while I study
"Try to ignore the GoTo's"
- I couldn't... I'll have to phone my therapist now
Are you talking about white space?
Yup. that 'Tab' key is really handy.
Basically, use your judgement with careful use to make it clear.
I'm not a line-feed person myself except where I want to separate a section visually.
No visual rules, just use your common sense.
But I'm sure we can drag this out for another few pages can't we?
- I couldn't... I'll have to phone my therapist now
Are you talking about white space?
Yup. that 'Tab' key is really handy.
Basically, use your judgement with careful use to make it clear.
I'm not a line-feed person myself except where I want to separate a section visually.
No visual rules, just use your common sense.
But I'm sure we can drag this out for another few pages can't we?
120ThingsIn20Years
Senior Member
I write and upload on linAXEPad, and simulate with the PICAXE software under Wine windows emulator (I cant get it to find the chip) and every time I open a linAXEPad file in the PICAXE software it adds an extra line feed after every existing line feed.
It drives me nuts.
I've taken to adding a ' at the beginning of every blank line in my code.
It drives me nuts.
I've taken to adding a ' at the beginning of every blank line in my code.
So what's your rule for indentation then? It sort of looks good at the start:This is what I've been doing so far.
Try to ignore the GoTo's
Code:CheckForLeverPress: If PinC.2 = 1 then Pause 50 GoSub Feed Endif GoTo CheckForLeverPress goto start1
- labels in col 1
- code indented 5 spaces
-...but then code inside a conditional indented another 4 spaces (why not 5?)
-...but then the code goes back to starting at col 1
You invited pedantry....
120ThingsIn20Years
Senior Member
120ThingsIn20Years
Senior Member
the 4 then 5 error is because I did it by eye as the tab button doesnt work in the <code> </code> tags.
I normally just use tabs.
And the "Goto Start1" being on the same indent is because I have no idea what I'm doing
Goto Start1 I would put 4 spaces to the left
Sorry it was a very poor example
It should have been this...
Code:
CheckForLeverPress:
If PinC.2 = 1 then
Pause 50
GoSub Feed
Endif
Return
Goto Start1I want to settle on a uniform approach, and I figure I may as well settle on one that shares some common ground with the rest of the universe.
Last edited:
Programmer: Hey boss, look, I finished the code for the Acme project !
Looks like we're gonna make the deadline and get the $20,000 performance bonus !
Manager: Great Lester, you're the man! ACME has been banging my
box for 5 days on this! They want it now ! Let me take a look .....
(30 minutes later ...)
What's this ? There's three Goto's in your C code! We can't ship this crap!
Programmer: Well, uh ... hmmm. Those Goto's saved me having to rewrite Bob's
section of the code so we could get it out the door and make the deadline. If I have
to rewrite Bob's code, that could take 3 - 5 more days and cost $3,000 - 5,000 more
in NRE. And ... we won't meet the performance bonus deadline. We are only providing
compiled code anyway so I don't see a problem.
Manager: There's a problem cause I say there's a problem! Haven't you read Dikjstra!
No one past kindergarten level programming uses GOTO anymore you lazy idiot!
This is a disaster!
Programmer: (With a quizical look)
Huh? ....OOOOoooo Kaaay. So what do you want me to do?
Manager: Do? ... Nothing!...You're fired ! Take your Goto's and get out of
my sight you lazy bum!
Programmer:
<Takes completed code disks and packs them up with other stuff and leaves>
< Dust flies as he exits the parking lot>
Manager: <Loud Shouting ...> BOB! ...... Get over here and fix this crap !
Bob ! ....... Bob ! ... Bob ! ...
Secretary: Sir.... You fired Bob last week for using too much white space in his
preliminary code. Don't you remember?
< 10 second pause>
Manager: Hey sweetie, get me a cup of coffee, and a Xanax ....and get Acme
on the phone. <Deep sigh>
Sheesh ! The things I have to go through around here to get stuff done!
lbenson
Senior Member
Regarding white space, your program won't fail to run properly because you use none, or are inconsistant, but if you do use it, consistancy is more important than any particular practice. The theory is that code at the same structural level should be at the same indentation.
What is a structural level? Well, a subroutine is pretty obviously a new structure. I start subroutine labels at the far left. The first line of code in the subroutine is indented (I'm with Dippy--I put blank lines before a subroutine label, and not in many other places). The branching and control commands indicate a new structure--IF, FOR, DO, SELECT CASE and any similar in any language. The beginning and end of those should be at the same level as the code it follows, but code within the branch or control statement should be indented (note that ELSE and ELSEIF are at the same level as IF). That pretty much covers it.
Decades ago I wrote programs of sufficient complexity that if I used 4 spaces of indentation, lines many levels deep would get pushed off to the right of the screen. So I just use two spaces. If I have to go back and add a level in the middle, I use one space. If I have to use two additional levels, I rework the indentation. I'm in the habit, I don't expect to change, or feel a need to.
For PICAXE Basic, 4 spaces will probably usually suffice--but use anything convenient that you find suitable.
What is a structural level? Well, a subroutine is pretty obviously a new structure. I start subroutine labels at the far left. The first line of code in the subroutine is indented (I'm with Dippy--I put blank lines before a subroutine label, and not in many other places). The branching and control commands indicate a new structure--IF, FOR, DO, SELECT CASE and any similar in any language. The beginning and end of those should be at the same level as the code it follows, but code within the branch or control statement should be indented (note that ELSE and ELSEIF are at the same level as IF). That pretty much covers it.
Decades ago I wrote programs of sufficient complexity that if I used 4 spaces of indentation, lines many levels deep would get pushed off to the right of the screen. So I just use two spaces. If I have to go back and add a level in the middle, I use one space. If I have to use two additional levels, I rework the indentation. I'm in the habit, I don't expect to change, or feel a need to.
For PICAXE Basic, 4 spaces will probably usually suffice--but use anything convenient that you find suitable.
Last edited:
Pretty funny made-up story.
How about a real-life story?
A programmer ignored coding and testing standards in a loan accounting system interest calculation module.
Three days into the accounting period the problem was discovered. Thousands of loans (millions of dollars in worth) were screwed up!
I had to rerun the month-end jobs (about a 12-14 hour process) and then rerun three days of daily transaction processing to correct the problem.
The loan accounting system fed data to the Accounts Receivable system which also had to rerun month-end and daily cycles.
I was in the office for about 36 hours to start the ball rolling and got very little sleep for several days until we got past it.
I don't believe that a GOTO was the problem, but it was sloppy code for sure.
We had structured walk-throughs by team members a lot more frequently after that incident. Standards are there for a reason.
hippy
Ex-Staff (retired)
But we mustn't forget companies pay the wages and set the rules, managers enforce those rules and it's for others to generally do as they are told, to comply with those rules.
Never the less, you are highlighting enforced requirements when they don't appear to have a legitimate rationale to them, and the rationale presented as justification is prejudicial and flawed, rather than proving requirements aren't needed.
What requirements there are should fit the needs of the business and the needs of the application, the programmer is there to fulfil those needs.
In an alternatively but equally extreme universe ...
"Hi Jim,
You remember that code which had GOTOs in and we told you we couldn't test it, had so much whitespace we couldn't understand it let alone verify it, the code you said ship anyway or we'd miss our twenty-K bonus ?
Well Acme had all their plant shut down, say it's "critical", and Fox news is reporting the entire eastern seaboard has "disappeared".
Hello ... Jim ...."
I worked as a programmer for a small UK company, many years ago. We had a contract with an oil company in Iraq.
The Director of the programming department went to Iraq (yes before all the hubbub), to demonstrate my cool new program. (It was supposed to collate lot's of oil pipeline temperature readings).
He did not tell me he was going, and he did not ask me for the latest version. He just helped himself to one of the disks in my disk box one day, and got on a plane.
A few days later, he was back and fuming at me!. He had taken the wrong disk with several partial versions, non working. I guess he had to blame someone.
I would have paid good money to see that meeting.
The Director of the programming department went to Iraq (yes before all the hubbub), to demonstrate my cool new program. (It was supposed to collate lot's of oil pipeline temperature readings).
He did not tell me he was going, and he did not ask me for the latest version. He just helped himself to one of the disks in my disk box one day, and got on a plane.
A few days later, he was back and fuming at me!. He had taken the wrong disk with several partial versions, non working. I guess he had to blame someone.
I would have paid good money to see that meeting.
Sounds like the "Peter Principle" at work. I have seen many managers who rose to a level where they were out of touch...I worked as a programmer for a small UK company, many years ago. We had a contract with an oil company in Iraq.
The Director of the programming department went to Iraq (yes before all the hubbub), to demonstrate my cool new program. (It was supposed to collate lot's of oil pipeline temperature readings).
He did not tell me he was going, and he did not ask me for the latest version. He just helped himself to one of the disks in my disk box one day, and got on a plane.
A few days later, he was back and fuming at me!. He had taken the wrong disk with several partial versions, non working. I guess he had to blame someone.
I would have paid good money to see that meeting.
While at that company, I heard amazing stories from my friend in the support department. Here's two:
-(On the phone) Client says 'It's asking me to insert disk 3, but I can't get it in with the other two disks.' (Old days of large floppy disks).
-(On the phone) Client says system has crashed. Support says do you have the backup disks? Client says yes, I am diligent about archiving backups. So the support guy drives 20 miles to the client and asks for the disks. He is given a ring binder with all the backup floppies in it. All of them HOLE PUNCHED to fit on the rings.
-(On the phone) Client says 'It's asking me to insert disk 3, but I can't get it in with the other two disks.' (Old days of large floppy disks).
-(On the phone) Client says system has crashed. Support says do you have the backup disks? Client says yes, I am diligent about archiving backups. So the support guy drives 20 miles to the client and asks for the disks. He is given a ring binder with all the backup floppies in it. All of them HOLE PUNCHED to fit on the rings.
I had another indcident with the same programmer who caused the incident I discussed earlier. I was looking at program code pulled from the source code library. All of the formatting (indentation, white space, line feeds, comments, etc) had been removed from the program.While at that company, I heard amazing stories from my friend in the support department. Here's two:
-(On the phone) Client says 'It's asking me to insert disk 3, but I can't get it in with the other two disks.' (Old days of large floppy disks).
-(On the phone) Client says system has crashed. Support says do you have the backup disks? Client says yes, I am diligent about archiving backups. So the support guy drives 20 miles to the client and asks for the disks. He is given a ring binder with all the backup floppies in it. All of them HOLE PUNCHED to fit on the rings.
It compiled and ran OK but it looked like a novel - not source code.
At first I thought the library software was corrupt but other programs looked fine. I checked the update log and then asked the programmer what happened.
He said he was saving space in the library by deleting the indentation, etc!!!
He had no concern for how unreadable or maintainable the program became.
Who wanted to make sense of that when the pager beeped at 3 a.m. after a program abend (crash)?!?!
Luckily, the Cobol compiler had an option for formatting the source code so I was able to get back into relative decent format.
He got moved to another team months later - thankfully!
I told him if he pulled another stunt like that, he would be looking for a new job.
Last edited:
Yep! Showing it's age but still used widely in large corporations - especially with large mainframe relational databases like DB2, Oracle, etc
Gentlemen: All this chit-chat about GOTO, yet some 8 pages of code nostalgia have developed without a mention of the '90s BOFH anti-hero. Check a few of his tales - they're compulsive reading!
120ThingsIn20Years
Senior Member
Strangely enough, all this stuff is actually helping me.
For one thing, it's relaxed me a little
Except perhaps the story of the hole punch and the floppys. That just added stress for some reason
My mum read the manual on the 4MHz PC I bought her second hand when they had just brought out the 286.
It said you had to format floppies before use.
So she wiped all her system disks.
The OS was already installed so it didn't really matter.
At least she read the manual
For one thing, it's relaxed me a little
Except perhaps the story of the hole punch and the floppys. That just added stress for some reason
My mum read the manual on the 4MHz PC I bought her second hand when they had just brought out the 286.
It said you had to format floppies before use.
So she wiped all her system disks.
The OS was already installed so it didn't really matter.
At least she read the manual
120ThingsIn20Years
Senior Member
If anyone is feeling generous, can you please tell me how I code these Ifs without the GoTo's?
I'm so stuck in goto's that I cant get them out of my head, and can't see a way out, because I dont want to exit, I want to exit and go back to the start.
I'm so stuck in goto's that I cant get them out of my head, and can't see a way out, because I dont want to exit, I want to exit and go back to the start.
Code:
Start1:'======= check for feed status==============================
Do
let LastFeed = time/OneMinute 'calculate and store the number of minutes since last feed
if FeedsRemain = 0 then
goto Start1 ' bail out of the loop if they cant have any more feeds
endif
if LastFeed < FeedWait then
goto Start1 ' bail out of the loop if time isnt up
endif
[stuff deleted]
Loop
End
Buzby
Senior Member
This might be what you are after :
Code:
Start1:'======= check for feed status==============================
Do
let LastFeed = time/OneMinute 'calculate and store the number of minutes since last feed
if FeedsRemain > 0 then
if LastFeed > FeedWait then
Do the feed stuff
Endif
Endif
Loop
End120ThingsIn20Years
Senior Member
Thanks...
I think
I'll see how that works with the stuff under it.
I'll have to simulate it to see what it does with the rest of the code. I find this so difficult to understand, that I cant even tell if that does what I need it to do
I wish I'd learnt it correctly from the start.
I still see an endless list of Ifs with GoTo Start1 easier to read than nested Ifs
Perhaps I should be using Select Case.
Thanks again.
I think
I'll see how that works with the stuff under it.
I'll have to simulate it to see what it does with the rest of the code. I find this so difficult to understand, that I cant even tell if that does what I need it to do
I wish I'd learnt it correctly from the start.
I still see an endless list of Ifs with GoTo Start1 easier to read than nested Ifs
Perhaps I should be using Select Case.
Thanks again.
@120, if you were to place your DO . . . LOOP within a DO . . . LOOP block, then your two goto statements could be replaced in toto with EXIT instructions and the code would/should work exactly as you have written it.
The EXIT instruction causing you to exit at the end of the current DO loop, which in your case would put you immediately back into an iteration of the new DO . . . Loop structure.
The EXIT instruction causing you to exit at the end of the current DO loop, which in your case would put you immediately back into an iteration of the new DO . . . Loop structure.
I don't know how I have resisted commenting so far. It is a good debate. It isn't snobbery, however. Obviously, in a trivial program that you are paying for you can do what you like. In the professional world however there are standards and those with experience do know that Gotos and other bad practices make code harder to understand (=more expensive to test and maintain).
For those learning to program from scratch it is probably a good idea to use good practice from day 1. Hence my remarks elsewhere and those of others. You never know, you might want a job as a programmer someday.
For some hardware engineers used to hand-relocating hex code, no doubt it is a step too far.
When Dijkstra wrote his paper, one of the main programming languages was FORTRAN (a nightmare to understand if not very carefully written), and back then BASIC had line numbers on every line, and gotos went to the line numbers, also a nightmare. Picaxe BASIC has absorbed many of the control structures that have been developed in the decades since Dijkstra, and is a pretty amazing language that can be used to write good code and control hardware at the same time.
After he published the paper, as a joke, someone proposed the 'Come From' as an alternative. According to Wikipedia, there are now languages with COMEFROM commands.
If you were ever to try to use logic to prove the correctness of software, as I have in the past (much academic work has been done on this), you would know that it is not the goto that is the problem. After all, that is clearly deterministic. The problem is that at the label it aims at you don't know where the flow will come from, assuming there are many gotos to the same label, which is common. Hence proof of correctness is impossible as the program flow is not coded in the program. Structures such as do/loop, select/case etc. are completely deterministic and thus you can prove correctness (in theory - in practice is a tad harder). What makes proving correctness difficult makes debugging difficult for the same reason.
In the world of tiny memory spaces when every byte has to earn its keep, then jumps are inevitable. In today's Picaxe world with relatively massive code space, there really is no reason not to use clearly written and understandable code for important projects.
Feel free to do as you like! But the only place you actually need a goto is to handle a serial timeout.
For those learning to program from scratch it is probably a good idea to use good practice from day 1. Hence my remarks elsewhere and those of others. You never know, you might want a job as a programmer someday.
For some hardware engineers used to hand-relocating hex code, no doubt it is a step too far.
When Dijkstra wrote his paper, one of the main programming languages was FORTRAN (a nightmare to understand if not very carefully written), and back then BASIC had line numbers on every line, and gotos went to the line numbers, also a nightmare. Picaxe BASIC has absorbed many of the control structures that have been developed in the decades since Dijkstra, and is a pretty amazing language that can be used to write good code and control hardware at the same time.
After he published the paper, as a joke, someone proposed the 'Come From' as an alternative. According to Wikipedia, there are now languages with COMEFROM commands.
If you were ever to try to use logic to prove the correctness of software, as I have in the past (much academic work has been done on this), you would know that it is not the goto that is the problem. After all, that is clearly deterministic. The problem is that at the label it aims at you don't know where the flow will come from, assuming there are many gotos to the same label, which is common. Hence proof of correctness is impossible as the program flow is not coded in the program. Structures such as do/loop, select/case etc. are completely deterministic and thus you can prove correctness (in theory - in practice is a tad harder). What makes proving correctness difficult makes debugging difficult for the same reason.
In the world of tiny memory spaces when every byte has to earn its keep, then jumps are inevitable. In today's Picaxe world with relatively massive code space, there really is no reason not to use clearly written and understandable code for important projects.
Feel free to do as you like! But the only place you actually need a goto is to handle a serial timeout.