Most of the languages in use today, do indeed have the goto statement. As we do already know, the goto statement is used to unconditionally jump from place to place within a program, with destinations marked as labels. As you can already guess, this can make a program really hard to read, with its particularly jumpy nature. The programmer, with all his wits, could well have written a perfectly unambiguous program, but what about his code? Sure ; he knows all about his own program, and is in a position to debug it and make changes, but what about debugging, when it comes to a team environment? While our smart programmer is on leave in Hawaii, rewarded for his hard work, how miserable life will be for his coworkers!
Oh, and did I mention the program had 352 goto statements?
In the days of the structured programmer, the goto statement was a very powerful tool in the hands of a very powerful programmer. His days, however, are no more. Neither him nor his tool are powerful anymore. However, it would be wrong to say that the goto statement does not have any application in high level programming. While some high level languages, like Java do not support the statement, other languages such as C#.NET continue to allow it ; and it proves to be useful in causing fall-throughs in switch-case blocks.
The popular saying among many, so-called high level programmers is, "Never use GOTO statements" ; but this need not be completely true. However, there have been several great computer scientists, whose work has formed the base for what most of computer science is today, have sternly voiced their concerns against the goto statement. The most popular of such cases is Edsger W. Dijkstra's letter to Communications of the Assosciation for Computing Machinery in 1968, titled A case against the go to statement. (here)
Since a number of years I am familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. Later I discovered why the use of the go to statement has such disastrous effects and did I become convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except –perhaps- plain machine code).
In reality, goto statements belong to assembly language code, where the program, has no other option, but to jump (conditionally or unconditionally) to memory locations, specified explicitly in the program itself. When structural programming was programmer fashion, the goto statement, as I already mentioned was a very powerful tool; but this was before the while and for loop even came into existence. Now, with better options at hand which were not available at earlier times, we must strive to do whatever we can to make our programs easier to manage, read and debug - we must strive to make our programs more high-level.
The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program.
The use of the word mess, in my opinion is quite apt. Imagine a program with 352 goto statements. You're probably going to spend more than half of your office hours scrolling up and down, trying to locate the labels, and make sense of what the program actually does. (And I'd sincerely hope you're not using the vi text editor.) Owing to this seemingly random flow of control between various statements, programs that use too many goto statements earn the "Spaghetti Code" nickname, which falls very short of a complement.
So why would you use a goto statement anyway? It is also a proven fact that every goto statement can be replaced with a suitable implementation of a set of looping constructs. (except for the fall through case in switch blocks I mentioned earlier). The reason for this is probably, that most programmers think (or like to think) in the way a computer thinks; executing a set of statements, and jumping to a new set of statements when a branching instruction is encountered. In a way, this is what dividing your programs into methods/functions also achieves, but it is much easier to manage code.
So, to conclude, to not go to is a much more sensible decision.
1 comments:
this feels good