| |
GOTO bashing |
| |
andrew (20:01 31/5/2004)
Phlamethrower (20:12 31/5/2004)
andrew (20:14 31/5/2004)
Phlamethrower (20:18 31/5/2004)
mavhc (06:35 1/6/2004)
john (09:25 1/6/2004)
andrew (11:04 1/6/2004)
andrew (18:13 2/6/2004)
ninj (14:42 4/6/2004)
adrianl (15:42 4/6/2004)
ninj (16:40 4/6/2004)
adrianl (17:20 4/6/2004)
ninj (21:54 5/6/2004)
rich (06:42 7/6/2004)
jmb (09:18 7/6/2004)
ninj (11:55 7/6/2004)
monkeyson2 (12:24 7/6/2004)
andrew (12:56 7/6/2004)
ninj (13:16 7/6/2004)
andrew (16:21 7/6/2004)
Loris (18:06 7/6/2004)
adrianl (03:13 8/6/2004)
ninj (11:56 8/6/2004)
adrianl (12:48 8/6/2004)
ninj (15:42 8/6/2004)
andrew (19:03 4/6/2004)
|
| |
|
Andrew |
Message #55114, posted by andrew at 20:01, 31/5/2004 |
 Handbag Boi
Posts: 3439
|
Have you ever read those comments that say 'don't use GOTO!'?
Well is that such a wise thing to be saying? For instance I've recently needed to skip a few lines during testing of a program I'm working on ased on a users choice, so I've added
IF choice$="N" THEN GOTO+18
Works fine for me which is not something I'd have done had I listened to all the oppressive conformists! |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #55119, posted by Phlamethrower at 20:12, 31/5/2004, in reply to message #55114 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Yes, GOTO's definitely have their place. However they should be used with care, because they aren't as sophisticated as line number independent labels used by 99% of the other languages out there. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #55120, posted by andrew at 20:14, 31/5/2004, in reply to message #55119 |
Handbag Boi
Posts: 3439
|
Maybe we could do with a Branch keyword. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #55123, posted by Phlamethrower at 20:18, 31/5/2004, in reply to message #55120 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Possibly, although that would (obviously) require a new statement or two adding to the language. A way of using GOTO's safely, on the other hand, would be to place REM statements at each GOTO destination. You'll then know where each GOTO goes to, so you can make sure you don't renumber/reorder/rewrite the lines without checking for side effects. |
| |
[ Log in to reply ] |
| |
|
Mark Scholes |
Message #55136, posted by mavhc at 06:35, 1/6/2004, in reply to message #55123 |
Member
Posts: 660
|
Possibly, although that would (obviously) require a new statement or two adding to the language. A way of using GOTO's safely, on the other hand, would be to place REM statements at each GOTO destination. You'll then know where each GOTO goes to, so you can make sure you don't renumber/reorder/rewrite the lines without checking for side effects. Until you remove all the REMs and it breaks. |
| |
[ Log in to reply ] |
| |
|
John D |
Message #55138, posted by john at 09:25, 1/6/2004, in reply to message #55114 |
Member
Posts: 261
|
Of course GOTO works fine, it's had plenty of testing. The point is that it's bad for the structure of the program; if you want that structure then don't use goto, if it works fine for you, then go ahead. Personally I'd put
IF choice$<>"N" THEN
..code 10 lines or whatever
ENDIF
and indent the bit in between.
Never let anyone tell you what to do, listen to thir reasoning and make your own decision. If theygive no reason then ignore them.
HTH :)
[Edited by john at 10:25, 1/6/2004] |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #55150, posted by andrew at 11:04, 1/6/2004, in reply to message #55138 |
Handbag Boi
Posts: 3439
|
Perhaps that would've been better although it's only for testing anyway.
[Edited by andrew at 12:04, 1/6/2004] |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #55333, posted by andrew at 18:13, 2/6/2004, in reply to message #55150 |
Handbag Boi
Posts: 3439
|
Just as a footnote: GOTO is not relative so putting a + in front of the 18 was misleading. In fact it just goes to line 18. |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55387, posted by ninj at 14:42, 4/6/2004, in reply to message #55114 |
Member
Posts: 288
|
It's less clear cut when it comes to testing, but personally I'd never use goto in production code. I probably wouldn't use it in test code either, but that's more personal preference as I believe it's a bad habit to get into in case you end up using it in production code.
I'd tend to do one of two things; if it's a short bit of code you skip, use a multiline if statement; if it's a chunk of code, factor it off into a procedure.
Actually, I have one rule of thumb even more significant than 'don't use GOTOs' - it's 'don't use BASIC'. The RISC OS python port is jolly good you know, and it's a cracking language. The other weekend I decided that I couldn't rely on the messageIDs of some emails I'd been processing so I needed to get a checksum of them as well. In Python I just imported the MD5 library and in a couple of lines of code I had an MD5 checksum of all text passing through the system and it didn't increase execution time by any more than 10%. I'd hate to see how long that'd take me to write in BASIC, and how long it'd take to run. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #55393, posted by adrianl at 15:42, 4/6/2004, in reply to message #55387 |
Member
Posts: 1637
|
It's less clear cut when it comes to testing, but personally I'd never use goto in production code. If you're objecting to GOTO in BASIC specifically, I'd be inclined to agree with you, generally. But I wouldn't use it for large projects anyway.
In other languages such as C, I'd ask you to please use goto where it's appropriate. I've seen some programmers write very twisted code just to avoid the use of 'the dreaded goto.' Typically involving repeated tests of error/finished flags where a simple 'goto error;' with the error handling code at the end of the function would have been a lot easier to read!
There's also an argument for it in performance-critical code such as the decode & dispatch loop of an interpreter/emulator but we all know that those functions should be written in assembler anyway! 
Oh, and look up Duff's Device if you're bored - case 'statements' are actually just labels like any other, and switch statements are just tables of gotos |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55396, posted by ninj at 16:40, 4/6/2004, in reply to message #55393 |
Member
Posts: 288
|
Actually I'm objecting to goto's in general. Small or large project (mainly because small projects have a habit of morphing into large projects anyway).
But I'll admit that maybe they're a better way of implementing that anti-pattern where you end up repeatedly testing the value of the error flag. A lot of the time this can be avoided by the judicious use of 'elsif'. That's still quite ugly, though I'd suggest if you have got a lot of code in a block then you probably should have written a function to do it anyway.
In C you can also just use a single case statement, and use break; to pop out of the block when you're done. Of course this is completely equivalent to 'goto end', except 'end' is going to be outdented one so it's likely to be easier to spot. You could do the same in Python with exception handling (which of course would be ideal for this particualar case). In perl, I thought there was a 'continue' statement or the likes which pops to the end of a block, but it seems that continue does something different. You could of course have while (1) { ... last; } - and if you have any 'last' statements inside the '...' they'll also pop to the end of the loop. That's quite misleading looking though.
Mainly I prefer to see indentation map directly to control flow, rather than magic GOTO's whisking the flow all over the place. Of course, BASIC's dependence on line numbers is just evil incarnate.
My argument falls down completely when it comes to optimising for performance though, but personally that's not something I do at the expense of readability. When you're working in a corporate environment with an average turnover of staff, unreadable code really can be a killer, and means a lot of code that works really well can be dropped just because noone can afford to spend the time unravelling it it to add minor feature x.
Anyway, rant over. As with all self-imposed 'laws' of coding, YMMV. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #55400, posted by adrianl at 17:20, 4/6/2004, in reply to message #55396 |
Member
Posts: 1637
|
In C code I've used it in Aemulor for code of the following form:
os_error *module_init()
{
err = claim_dabt();
if (err) goto failed3;
err = claim_pabt();
if (err) goto failed2;
err = claim_swi();
if (err) goto failed;
err = claim_und();
if (!err) return NULL;
failed: release_pabt();
failed2: release_dabt();
failed3:
return err;
}
I personally find this clearer (but for the lack of indentation in this post!) than the 'structured' alternative:
err = claim_dabt();
if (!err)
{
err = claim_pabt();
if (!err)
{
err = claim_swi();
if (!err)
{
err = claim_und();
if (!err) return NULL;
release_swi();
}
release_pabt();
}
release_dabt();
}
return err;
Out of curiosity, earlier I searched the Aemulor search for occurrences of 'goto' and they're all every-handling and tidying up, like the above. The fact that it's Aemulor isn't relevant, BTW, since all the performance-critical code is in assembler (naturally!); about 2/3 of the source in fact!  |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #55405, posted by andrew at 19:03, 4/6/2004, in reply to message #55387 |
Handbag Boi
Posts: 3439
|
It's less clear cut when it comes to testing, but personally I'd never use goto in production code. I probably wouldn't use it in test code either, but that's more personal preference as I believe it's a bad habit to get into in case you end up using it in production code.
I'd tend to do one of two things; if it's a short bit of code you skip, use a multiline if statement; if it's a chunk of code, factor it off into a procedure.
Actually, I have one rule of thumb even more significant than 'don't use GOTOs' - it's 'don't use BASIC'. The RISC OS python port is jolly good you know, and it's a cracking language. The other weekend I decided that I couldn't rely on the messageIDs of some emails I'd been processing so I needed to get a checksum of them as well. In Python I just imported the MD5 library and in a couple of lines of code I had an MD5 checksum of all text passing through the system and it didn't increase execution time by any more than 10%. I'd hate to see how long that'd take me to write in BASIC, and how long it'd take to run. BASIC is a wonderful language and opens doors for endless users. Not perfect but let's hope it's developed (and documented) further. |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55421, posted by ninj at 21:54, 5/6/2004, in reply to message #55400 |
Member
Posts: 288
|
Andrew: BASIC is an evil language. However, having any language built into the OS is a great thing. Maybe BASIC is easier to get into even than the mighty (currently) Python. In both cases, 'Hello World' is a one-line program, though in Python you have to start learning things like namespaces earlier. However, I beleive shortly after in BASIC you'll have to start doing nasty things to get around strict limitations in its variable handling. Besides, namespaces aren't all bad - without them it'd be a lot clunkier to do MD5 checksums (as per my previous example).
adrianl: Surely my suggestion of using a case statement in C is neater than the fully structured approach? Such as (though my C's rusty enough that I'm really not sure this is legal):
switch (1) {
case 1:
blah;
if (!correct) {
err = 1;
break;
}
if (!working) {
err = 1;
break;
}
}
if (err) {
print "Bank!"; return NULL;
}
(of course, if IconBar allowed indenting that'd look a lot better) |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #55464, posted by rich at 06:42, 7/6/2004, in reply to message #55421 |
 Dictator for life
Posts: 6828
|
(of course, if IconBar allowed indenting that'd look a lot better) Blame HTML, not us. And try using hard spaces, not soft ones.
________
 Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
JMB |
Message #55467, posted by jmb at 09:18, 7/6/2004, in reply to message #55464 |
Member
Posts: 467
|
(of course, if IconBar allowed indenting that'd look a lot better) Blame HTML, not us. And try using hard spaces, not soft ones.
umm. what's wrong with the <pre> tag? |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55471, posted by ninj at 11:55, 7/6/2004, in reply to message #55464 |
Member
Posts: 288
|
(of course, if IconBar allowed indenting that'd look a lot better) Blame HTML, not us. And try using hard spaces, not soft ones.
I couldn't get to work, when I tried it. Mind you, I was quite tired - I've no idea why I wrote 'Bank!' |
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #55475, posted by monkeyson2 at 12:24, 7/6/2004, in reply to message #55471 |
 Please don't let them make me be a monkey butler
Posts: 12380
|
Mind you, I was quite tired - I've no idea why I wrote 'Bank!' Been watching too much Weakest Link? |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #55478, posted by andrew at 12:56, 7/6/2004, in reply to message #55421 |
Handbag Boi
Posts: 3439
|
What kind of variable restrictions?
BASIC allows very powerful programs to be knocked up in a very short time and obviously there's assembler built in. |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55479, posted by ninj at 13:16, 7/6/2004, in reply to message #55478 |
Member
Posts: 288
|
variable restrictions - things like not being able to have nested lists. Thinks like not having (or being able to construct) linked lists (so you can insert items) or hash tables (for superfast key->value lookups) without memory hacks. Not being able to create at least structures, so you can send, for example, complex numbers as a single variable. Not being able to do operator overloading so that if you did have a complex number you can still add one to it by doing num+=1 - and not caring if it's a real or complex numbers.
None of these things can't be worked round - of course, since it's a turing complete language like any other. It's just a lot /nicer/ in more modern languages. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #55484, posted by andrew at 16:21, 7/6/2004, in reply to message #55479 |
Handbag Boi
Posts: 3439
|
DIM pretty powerful and Castle have extended it further. Also matrix multiplications and isn't there a way of redefining whole arrays with a single statement in BASIC?
What is 5 bytes for a real number if not complex? What happened to BASIC 64 as well? |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #55485, posted by Loris at 18:06, 7/6/2004, in reply to message #55484 |
 Ha ha, me mine, mwahahahaha
Posts: 1025
|
What is 5 bytes for a real number if not complex? He means complex in the mathmatical sense. Briefly, complex numbers have two components, a real part and an 'imaginary' part.
For example: 5+6i
The imaginary part is created by taking the square root of a negative number. They are useful under certain circumstances.
As ninj says, it can all be worked around (for example I think linked lists can be done fairly trivially) but it can be a pain. But then again, all languages have problems when used inappropriately.
Back on topic, no assembler programmer has a problem with GOTOs. All loops involve them. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #55486, posted by adrianl at 03:13, 8/6/2004, in reply to message #55485 |
Member
Posts: 1637
|
He means complex in the mathmatical sense. Briefly, complex numbers have two components, a real part and an 'imaginary' part.
For example: 5+6i
The imaginary part is created by taking the square root of a negative number. They are useful under certain circumstances. To, I hope, further clarify, i = sqrt(-1) and the expression x + yi is best thought of as the position (x,y) on a 2D grid where x is the position on the horizontal ('real') axis and y is the position on the vertical ('imaginary') axis (at 90 degrees to reality if you will! ). A complex number is formed from a real part and an imaginary part.
This is A-level maths/university-level material, though, so don't worry if you don't understand, but it does prove useful in modelling & understanding electrical systems. OTOH if you decide to go into pure computer science you need never worry about it - it's for mathematicians and engineers AFAIK! |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55490, posted by ninj at 11:56, 8/6/2004, in reply to message #55486 |
Member
Posts: 288
|
This is A-level maths/university-level material, though, so don't worry if you don't understand, but it does prove useful in modelling & understanding electrical systems. OTOH if you decide to go into pure computer science you need never worry about it - it's for mathematicians and engineers AFAIK! Quite. I was just trying to think of an example of a fairly generic object that required multiple variable to represent, and upon which mathematical operations were different to that of normal (real) numbers. Complex numbers was the best one I could think of off the top of my head, but even that requires a fair bit of domain knowledge! |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #55493, posted by adrianl at 12:48, 8/6/2004, in reply to message #55490 |
Member
Posts: 1637
|
I was just trying to think of an example of a fairly generic object that required multiple variable to represent... A database record would be a simple example of a structure - name, address, telephone number and so on. |
| |
[ Log in to reply ] |
| |
|
ninjah |
Message #55506, posted by ninj at 15:42, 8/6/2004, in reply to message #55493 |
Member
Posts: 288
|
You can't really show operator overloading with that example though. Not that I use operator overloading very often, mind. |
| |
[ Log in to reply ] |
| |
|
