goto... Who uses it?
-
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 nowadays in assembly (no choice) and scripting languages that don't have good structured programming constructs (ie. if/then/else etc.). I learned programming in the days of early Fortran IV (and actually regressed a little on an older machine with Fortran IID) that only had arithmetic if[^] and computed goto[^] for conditional logic flow. I really came to appreciate the evils of the 'goto' statement and never use them unless there is no other choice. If I use a goto, it will always transfer control downwards, never up. And yes, I use break and continue, and multiple returns in methods.
-- Harvey
-
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.
.Net framework uses that. They just built some fancy keywords that do the same thing but have a different name. For instance, continue.
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
-
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.
goto... Who uses it? Only those programmers who want to be slowly boiled in hot oil
If it's not broken, fix it until it is
-
.Net framework uses that. They just built some fancy keywords that do the same thing but have a different name. For instance, continue.
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
If you think the 'continue' keyword is anything at all like 'goto', you need to go back to programming 101.
If it's not broken, fix it until it is
-
Thats swift. I'll be the first to admit that I dont have the experience or knowledge of 90% of the people here. Interesting.
DanielSheets wrote:
I'll be the first to admit that I dont have the experience or knowledge of 90% of the people here.
The fact that you care about readability proves that you can't be in the bottom 10% :) Readable code leads to maintainable projects. The better a project can be maintained, the more chances it will survive in the long run.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I only use it nowadays in assembly (no choice) and scripting languages that don't have good structured programming constructs (ie. if/then/else etc.). I learned programming in the days of early Fortran IV (and actually regressed a little on an older machine with Fortran IID) that only had arithmetic if[^] and computed goto[^] for conditional logic flow. I really came to appreciate the evils of the 'goto' statement and never use them unless there is no other choice. If I use a goto, it will always transfer control downwards, never up. And yes, I use break and continue, and multiple returns in methods.
-- Harvey
-
DanielSheets wrote:
I'll be the first to admit that I dont have the experience or knowledge of 90% of the people here.
The fact that you care about readability proves that you can't be in the bottom 10% :) Readable code leads to maintainable projects. The better a project can be maintained, the more chances it will survive in the long run.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
Readable code leads to maintainable projects. The better a project can be maintained, the more chances it will survive in the long run.
.... which is completely offset by his use of 'goto'.
If it's not broken, fix it until it is
-
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.
-
goto... Who uses it? Only those programmers who want to be slowly boiled in hot oil
If it's not broken, fix it until it is
-
That's horrible. Repeated code, and mixing of data management and UI code. It's crying out for throwing exceptions which you catch in the UI code, and a method
int parseNumericValue(String text){
int result;
if(!int.TryParse(text == "" ? "0" : text, out result))
throw new DataFormatException("Unable to parse data. Verify its entered correctly.\r\nValue = "+text);
return result;
}(and that's if the default exception from Parse doesn't do the job which it probably does). This is translated VB. And that's not a good thing.
Where do you see UI code in the snippet I posted?
-
If you think the 'continue' keyword is anything at all like 'goto', you need to go back to programming 101.
If it's not broken, fix it until it is
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[^]
-
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'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; -
That's horrible. Repeated code, and mixing of data management and UI code. It's crying out for throwing exceptions which you catch in the UI code, and a method
int parseNumericValue(String text){
int result;
if(!int.TryParse(text == "" ? "0" : text, out result))
throw new DataFormatException("Unable to parse data. Verify its entered correctly.\r\nValue = "+text);
return result;
}(and that's if the default exception from Parse doesn't do the job which it probably does). This is translated VB. And that's not a good thing.
I would one step further since the ternary test is not only silly, it might throw an exception all on it's own due to text being null. If you KNOW something is "0", why parse it to 0? Why is an empty string valid? Is a null string valid? The code has other problems. Why create the file before you know whether there are any errors? Why set totalDelays and value back to zero? "its" is spelled "it's" in this context, but it should probably read "it was".
-
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