|
|
The loop one times construct can be useful.
Where I've used it is when I've had to work with a long sequence of if else/if's, and used break to exit. For instance:
while (true)
{
if (set (ifrFragment))
{
result = true;
ifrTerm = ifrFragment;
break;
}
if (errorCode)
break;
if (keyword (TokenSubtype::Not) && term (ifrFragment))
{
result = true;
ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment;
break;
}
if (errorCode)
break;
break;
}
But the switch/case in your example would lead me to believe that lnIndice had other values at some point, perhaps for debugging.
|
|
|
|
|
lol. Haven't seen that done in a long time. We used to do it to piss off the "never use goto" zealots years ago when forbidden to use 'goto xit' for handling error conditions.
|
|
|
|
|
Robert Surtees wrote: We used to do it to piss off the "never use goto" zealots years ago when forbidden to use 'goto xit' for handling error conditions.
Robert, I use goto's for exactly the same reason.
if (keyword (TokenSubtype::Group))
{
if (!group_label (groupName))
{
errorMessage = myName + ": Missing GROUP label\n" + errorMessage;
errorCode = DL_ERROR;
goto exit_;
}
if (!separator (TokenSubtype::Colon))
{
errorMessage = myName + ": Missing colon following GROUP label";
errorCode = DL_ERROR;
goto exit_;
}
|
|
|
|
|
I use goto only to break out of >1 nested loops... Don't see the need for it anywhere else...
|
|
|
|
|
The rollback from a list of initialization steps maybe another valid usage.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
|
I aint affraid to use it bubba joe I just don't see the need for it... At least in C#...
|
|
|
|
|
C#? Sounds like a language for quiche eaters.
Seriously, there are times when nested if/else constructs get unweildy. In some cases, albeit rarely, I'd rather use a goto. I only use them to transfer control either to a error handling section or a single exit point.
|
|
|
|
|
Tony Wesley wrote: I use goto's
It's OK, so do I, in C#!
xacc.ideIronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
So what happens to your "goto" cleanup routine when an exception is thrown?
I'll give you a hint -- it doesn't get called.
|
|
|
|
|
CurtD wrote: So what happens to your "goto" cleanup routine when an exception is thrown?
I'll give you a hint -- it doesn't get called.
The goto doesn't figure into that. Just above it in the thread is another snippet of my code that doesn't use a goto.
Same issue. What happens to the code after the while loop when an exception is thrown? It doesn't get executed.
Once could argue that the problem is with exception. As I pointed out elsewhere, Joel Spolsky argues that exceptions [...] create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: (emphasis added)
I don't quite agree with Joel. But there was a time, when I was debugging an app that another programmer had written, that I understood that completely. It was spaghetti exception handling. I never knew where I had come from.
I'm not saying you shouldn't use exceptions. But they can be abused as badly as gotos.
|
|
|
|
|
Tony Wesley wrote: The goto doesn't figure into that. Just above it in the thread is another snippet of my code that doesn't use a goto.
Same issue. What happens to the code after the while loop when an exception is thrown? It doesn't get executed.
Once could argue that the problem is with exception. As I pointed out elsewhere, Joel Spolsky argues that exceptions [...] create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: (emphasis added)
I don't quite agree with Joel. But there was a time, when I was debugging an app that another programmer had written, that I understood that completely. It was spaghetti exception handling. I never knew where I had come from.
I'm not saying you shouldn't use exceptions. But they can be abused as badly as gotos.
I'm talking about the case where coders like to put a block of cleanup code at the bottom of a method and "goto" it when something goes wrong or fall into it in a non-error situation. If you are depending on blocks of cleanup code, an exception will bypass it completely. This worked back in C, but not in OO design.
That's why I use objects that clean themselves up when destroyed -- automatically. I am far too lazy to try to figure out every possible error situation, catch exceptions from anything that might throw them, and ensure that there is an appropriate goto.
I disagree completely with Joel Spolsky. He suggests using return codes instead of exceptions. Return codes and exceptions are completely different things. Exceptions are not meant to be return codes. They are "exceptional" situations where usually the app cannot continue. And exceptions have the major advantage of unwinding the stack, which he fails to mention. They are not "an abrupt jump from one point of code to another."
It seems like OO programming has really failed to catch on with a lot of developers.
modified on Sunday, December 16, 2007 12:10:46 AM
|
|
|
|
|
But then why not
do
{
...
} while ( false ) ;
|
|
|
|
|
|
heh.
of course that's just a coding-standards-compliant way of writing:
if (set (ifrFragment))
{
result = true;
ifrTerm = ifrFragment;
goto done;
}
if (errorCode)
goto done;
if (keyword (TokenSubtype::Not) && term (ifrFragment))
{
result = true;
ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment;
goto done;
}
if (errorCode)
goto done;
done:
|
|
|
|
|
|
You're sure you're not mistaking that "one" in lnIndice <= 1 for an "ell"?
Marc
|
|
|
|
|
Only a real programmer who codes in raw hex, or someone very daft, or someone with the editor font set to one with massive differences between 1 and l would ever call a variable "l".
i, on the other hand...
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
That's what I call extendable coding.
|
|
|
|
|
FINALLY!!!!
My first entry on a coding horror!
Is this a sign I am starting to learn, possibly, but even in goood old fashioned ms basic circa 1981 I would have spotted this load of old codswallop!
So pleased to say that I would never have done this!
------------------------------------
Happy Primes Lead to Happy Memories.
Don't Google FGI
|
|
|
|
|
heheheh . Cool thing....i myself as developer can understand that sort of things can happen when code passes through certain hands without proper comments.
|
|
|
|
|
Whether it was the basement of great code or the ruin of an unlucky project. Who knows...
A good optimized cempiler would clean this up.
Greetings from Germany
|
|
|
|
|
omg.. what else is there to say ??
Michael Davey
biproject.com rss and blog news in a more palatable format
mobile edition now available!
|
|
|
|
|
- Pascal - wrote: We found it very funny
I find it quite useful, actually. This is the sort of thing that sits in code that is prone to change. Why destroy the entire structure when a month or two from now, someone has a need to add in an index of 2 and 3?
Though, admittedly, I'd comment out everything but the 'do something' code when it got this low. But I'd still leave it THERE.
|
|
|
|