goto... Who uses it?
-
Where do you see UI code in the snippet I posted?
MessageBox.Show
-
I beg to differ here. Check out the IL generated for the two methods:
void Test()
{
while (true)
{
string str = "Something";if (str.Length != 10) { continue; } } } void Test2() { x: while (true) { string str = "Something"; if (str.Length != 10) { goto x; } } }//without GOTO .method private hidebysig instance void Test() cil managed { // Code size 32 (0x20) .maxstack 2 .locals init ([0] string str, [1] bool CS$4$0000) IL_0000: nop IL_0001: br.s IL_001c IL_0003: nop IL_0004: ldstr "Something" IL_0009: stloc.0 IL_000a: ldloc.0 IL_000b: callvirt instance int32 [mscorlib]System.String::get_Length() IL_0010: ldc.i4.s 10 IL_0012: ceq IL_0014: stloc.1 IL_0015: ldloc.1 IL_0016: brtrue.s IL_001b IL_0018: nop IL_0019: br.s IL_001c IL_001b: nop IL_001c: ldc.i4.1 IL_001d: stloc.1 IL_001e: br.s IL_0003 } // end of method Proof::Test //With GOTO .method private hidebysig instance void Test2() cil managed { // Code size 32 (0x20) .maxstack 2 .locals init ([0] string str, [1] bool CS$4$0000) IL_0000: nop IL_0001: br.s IL_001c IL_0003: nop IL_0004: ldstr "Something" IL_0009: stloc.0 IL_000a: ldloc.0 IL_000b: callvirt instance int32 [mscorlib]System.String::get_Length() IL_0010: ldc.i4.s 10 IL_0012: ceq IL_0014: stloc.1 IL_0015: ldloc.1 IL_0016: brtrue.s IL_001b IL_0018: nop IL_0019: br.s IL_0001 IL_001b: nop IL_001c: ldc.i4.1 IL_001d: stloc.1 IL_001e: br.s IL_0003 } // end of method Proof::Test2
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
The two examples you posted are NOT the same. The second one restarts the 'while' loop all over again, while the first one continues with the next iteration of the same loop. The goto had a totally different effect than the continue Paste this into a console app and walk it through:
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Test();
Test2();Console.ReadLine(); } static void Test() { Console.WriteLine("Test"); int x = 0; while (true) { x++; if (x < 10) { continue; } Console.WriteLine(x); } } static void Test2() { x: Console.WriteLine("Test2"); int x = 0; while (true) { if (x < 10) { goto x; } Console.WriteLine(x); } } }}
The first one starts printing at 10 and never stops because of the continue. The second one never does anything expect print "test2" because of the goto. 2 entirely different functionalities between 'goto' and 'continue'
If it's not broken, fix it until it is
-
MessageBox.Show
Touché
-
In SQL - fairly often to jump to the error handler at the end of our sprocs. I'll admit there's no good reason we do this, since it's easy enough for us to avoid this with if statements, but it's a pattern used in our original code and so for consistency we stuck with it:
Create Procedure MyProc as
Begin Tran -- Do stuff... if @@error <> 0 goto errorHandler Commit Tran Return 0errorHandler:
Rollback Tran
Return 1cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
since it's easy enough for us to avoid this with if statements
There is an
IFstatement, it just lacks theELSE. :confused:"The ones who care enough to do it right care too much to compromise." Matthew Faithfull
-
Many a word has been written about the use of multiple exits being bad practice. Perhaps the next discussion should be on the use of many returns.
Q. Hey man! have you sorted out the finite soup machine? A. Why yes, it's celery or tomato.
dusty_dex wrote:
Many a word has been written about the use of multiple exits being bad practice.
I think I understand the issue from all sides and I don't drink that kool-aid. The way I look at it, the goto takes linear flow and folds it back on itself, causing the programmer to think about an interleaved mesh of logic instead of a stream. I see the following items as presenting different concepts and approve/disapprove of each on their own merits: (1) goto backwards within a loop (2) goto forwards within a loop (3) goto forwards to exit handler/error handler at end of method (4) break statement in a loop (4a) bounded loop (4b) infinite loop (ie. exit in the middle) (5) break statement in a switch() (6) continue statement in a loop (7) return statement inside a loop (one only per method) (8) multiple return statements in a method History has shown that #1 has caused the most problems, and #2 follows closely. #3 seems to be the one that most people defend, and I think it has some merit. I have used #3 but I still avoid it whenever I can. I regularly use all of #4 through #8 and have no problem with them. Multiple returns in a method are really no different from a break statement in terms of how the programmer's brain processes the logic. Multiple returns cause an exit from a method (so there is no tortured logic flow), you can debug it (eg. you can put a breakpoint on it), do not fold logic back (so that you can get to a statement from multiple directions) and can reduce the amount of code in a method (less code is better code). Probably other things too - this is off the top of my head.
-- Harvey
-
The two examples you posted are NOT the same. The second one restarts the 'while' loop all over again, while the first one continues with the next iteration of the same loop. The goto had a totally different effect than the continue Paste this into a console app and walk it through:
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Test();
Test2();Console.ReadLine(); } static void Test() { Console.WriteLine("Test"); int x = 0; while (true) { x++; if (x < 10) { continue; } Console.WriteLine(x); } } static void Test2() { x: Console.WriteLine("Test2"); int x = 0; while (true) { if (x < 10) { goto x; } Console.WriteLine(x); } } }}
The first one starts printing at 10 and never stops because of the continue. The second one never does anything expect print "test2" because of the goto. 2 entirely different functionalities between 'goto' and 'continue'
If it's not broken, fix it until it is
-
If that's T-SQL in anything resembling modern SQL Server, there are much, much better constructs for error handling now.
try..catch is so bourgeois.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
Fortran IV made extensive use of them. I used to love them at the time. Since then, I've never used them. Perhaps they do have a use and if teams that write compilers put them in then whose to argue for and against?
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
I only use it in shell scripts/batch files, and I am working on setting up Python as my default Windows shell system. That will take some work, but I think it will be worth it!
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
None dare mention the fact that "break" and "goto" are really the same thing
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
I hate being restricted by programming standards that explicitly say "you should not use gotos". What is the point of using a language that has gotos and not being allowed to use them. It is like someone giving you an ornamental chocolate and your mum telling you that you aren't allowed to eat it because it looks pretty. Why did they give it to us if we weren't meant to eat it. Why does a language have gotos if we are not allowed to use them.:confused: When I was in airlines, the technical manager said that if anyone wanted to use gotos, he wanted a writeup of reasons. Now here was a challenge: all I had to do was reproduce the essay "structured programming using gotos" which I wrote when I was in Uni (1976), with snippets of how much simpler the code was with gotos than without. It was about 3 pages. The goto restriction was lifted for me and no one ever questioned it. The same thing happened when I was in medical. Guess they had never dealt with a real computer scientist before. Everyone else was an ex engineer, astronomer, mathematician or physicist. They just read about programming concepts: they never had to do the research or write up essays on simple, everyday things like use of do-while-false loops or indentation styles.
-
I've not used it in 15 years or so, in any of my C# or C++ applications. There are too many better alternatives to
gotoin those languages. The last time I usedgotowas in C in the 90's, when the compilers I was using didn't (reliably) support exceptions.Software Zen:
delete this;I try to squeeze at least one in at every site where I've worked, just to prove a point (the points being, nobody reads the programming standards and not many people actually read code). I've succeeded in 6 out of 9.
-
DanielSheets wrote:
It can make for cleaner code if used correctly.
Your definition of "cleaner code" is quite odd then. There is no "correct" usage of it in modern high level languages. It simply creates an unmaintainable ball of string.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
That looks bad to me. Aren't you supposed to use
break ;
to jump out of loops? Exception handling will usually bog down the handled block of code.
Q. Hey man! have you sorted out the finite soup machine? A. Why yes, it's celery or tomato.
-
In SQL - fairly often to jump to the error handler at the end of our sprocs. I'll admit there's no good reason we do this, since it's easy enough for us to avoid this with if statements, but it's a pattern used in our original code and so for consistency we stuck with it:
Create Procedure MyProc as
Begin Tran -- Do stuff... if @@error <> 0 goto errorHandler Commit Tran Return 0errorHandler:
Rollback Tran
Return 1cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
An error condition returns the same value as a non-error condition? Many hamsters are dying because of that.
Oops. Typo.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Fortran IV made extensive use of them. I used to love them at the time. Since then, I've never used them. Perhaps they do have a use and if teams that write compilers put them in then whose to argue for and against?
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
Blame has been put on the goto statement by a very famous article. In the old days of FORTRAN, with its old fashioned control statements, including conditional, assigned and computed goto's, or in early versions of the Basic language with its goto/gosub mechanisms, you had little other option to control the flow of execution than branching to numeric labels. Writing clean code was indeed a challenge, as it was hard to make the structure of the code apparent. Things have changed a lot thanks to structured languages so that pinches of goto's every here and there are quite acceptable, and possibly more advisable than some contortions used to avoid them at all costs. My favorite usage is when implementing state machines, every state being represented by a jump label and the decision-making block of code following it, which includes a number of explicit branches to other states. Such coding can involve tenths of goto's, while remaining crystal clear readable.
-
In SQL - fairly often to jump to the error handler at the end of our sprocs. I'll admit there's no good reason we do this, since it's easy enough for us to avoid this with if statements, but it's a pattern used in our original code and so for consistency we stuck with it:
Create Procedure MyProc as
Begin Tran -- Do stuff... if @@error <> 0 goto errorHandler Commit Tran Return 0errorHandler:
Rollback Tran
Return 1cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Hasn't T-SQL had
try-catchsince 2005? -
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
I'm still using GOTOs, not in my C# / JAVA / C++ code but in my SQL Code. It is still very usefull in SQL for error handling, MS introduced the BEGIN/END TRY/CATCH structure but it is not portable on version of SQL older than 2005 and it is absolutely not portable "as is" on another SQL Engine and most of the customers I've worked for have that mandatory requirement to be able to switch engine as they see fit (even if 90% of them will never take that step and stick to MS SQL Server).