November 18, 2015 at 13:33

Goto or not goto that's the question

“A dispute is possible where the truth is closed. In futile disputes, you can endlessly discuss what is in the room with a closed door. But once the door is opened, it will become clear to everyone and there’s nothing to argue about, since everyone can see the truth. ”

Vladimir Megre The



article is dedicated to Zatsepin P.M., an outstanding engineer of Altai State University, under whose strict guidance many students, including the author of the article, comprehended the magic of engineering.

Introduction


The debate about the possibility of using the GOTO operator in the programs has been going on for a very long time (Dijkstra's article “On the Dangers of the GOTO Operator,” published in 1968 [2], is recognized as its official beginning). In three years we will celebrate the 50th anniversary of this dispute. This is a good reason to finally “dot all i” and end the argument.

The citation in the epigraph is not accidental. It accurately reflects the current situation in the GOTO dispute. In our case, “a room behind a closed door” is a statement of the problem that is clear to everyone. So far, unfortunately, such a statement of the problem has not been announced, so the debate does not fade away. The warring parties argue about similar things, but still about different things, and therefore can not find a compromise.

Let us take the neutral side in this dispute, and we will sort out everything impartially. Consider the arguments of the “opponents” and “defenders” of the GOTO operator and decide “which of them is right and who is to blame”.

Why disputes are ongoing


As noted above, disputes about the possibility of using the GOTO operator in the programs are being conducted due to the lack of a clear statement of the problem. Roughly speaking, one side proves that the tree is floating, and the other that the brick is sinking. Naturally, with such a statement, each of the parties is confident in its correctness and will always uphold it.

GOTO opponents rely on good manners. It is here that the key to the "closed door" is hidden, because there are at least three rules of good tone: “good tone in structuring”, “good tone in speed” and “good tone in compactness”, but opponents of GOTO consider only one of them.

GOTO defenders rely on customer requirements, where, among others, items related to the speed and compactness of the program are not rare. With such a statement one good manners cannot be dispensed with - one has to look for a compromise solution. As a result of such a decision, the GOTO operator sometimes appears in the program.

In this case, it is difficult to distinguish a brick from a log, because lately, less attention has been paid to the development of speed and compactness programs. But this is not a reason to completely ignore them, because there must be a supply for any demand.

The voiced point of view is very superficial, because does not take into account the details of the dispute. In order to formulate an objective statement of the problem, it is necessary to consider the arguments and counterarguments of each of the parties. This is what we will do now. The bold letters Z are the arguments of the GOTO defenders, and the bold letters P are the arguments of the GOTO opponents.

The arguments of the "opponents" GOTO


1. Using GOTO is a bad tone.
Z: This is an unreasonable statement, so there is no point in arguing here.

2. The worst tone is returning with a mark back.
Z: Indeed, you cannot use GOTO in this way, just as you can’t use it to move to another block of the scope - you can either stay in the current one or leave it. If you follow these two rules, then you can use GOTO.

3. GOTO - redundant operator. It can easily be replaced by cycles and conditions.
Z: For that matter, almost all operators can be thrown out of the language.

From the point of view of structural programming, all operators can be thrown out of the language, leaving only while and the assignment operator. [1] In this case, the programs will be voluminous, but understandable. If, in practice, attention was paid only to the structure of the program, then such a step would be reasonable, but in real problems there are still requirements for speed and compactness, and this cannot be achieved with one operator.

GOTO is a sign of not curvature of the code, but the curvature of languages ​​in which sometimes without it (C, C ++, C #, Pascal, Java, etc) and the curvature of profanity called "structural programming" with its so-called “Cycles with preconditions”, “cycles with postconditions” and “branches”, which are not elementary constructions, but typical patterns into which the task does not always fit comfortably.

The inconvenience is that if the task does not fit perfectly into these patterns, then redundant code appears, which in some cases does not satisfy the requirements of compactness and speed.

4. Wirth and Dijkstra say that GOTO is bad. [2, 3]
Z: Authoritative opinions are noteworthy, but what authorities say is not the ultimate truth. It’s not without reason that the phrase “If a respected scientist says that“ it is possible to do it ”is common, he is most likely right, and if he says that“ it is impossible to do it, then he’s most likely not right. ”

There are also authorities who speak out in favor of GOTO, for example, Donald Knuth [4], Fredrick Brooks. [5] But in solving the problem it is more expedient to rely not on the opinion of authorities, but on common sense.

5. GOTO nullifies many of the compiler's options for optimizing control structures, which makes the code slower and more voluminous. [2]
Z: This problem is in no way related to GOTO, as optimization is done at the level of machine codes. Yes, GOTO inserts a jump instruction into machine code, which prevents code optimization, but the conditional statement and loop statements also insert the same instructions.

GOTO Defenders Arguments


1. A group of mutually exclusive conditions.
Sample Code ...
if(objectA.nValue == objectB.nValue)
{
	...
	goto END;
}
if(objectC.nValue == objectD.nValue)
{
	...
	goto END;
}
if(objectE.nValue == objectF.nValue)
{
	...
	goto END;
}
END: ...

if(objectA.nValue == objectB.nValue)
{
}
else if(objectC.nValue == objectD.nValue)
{
}
else if(objectE.nValue == objectF.nValue)
{
}
…


P: In this case, GOTO does not spoil the program structure, but there is no practical need for such a construction, because the same can be arranged via if / else.

Z: You can replace the given code with if / else only if no additional operations are performed before completion.

P: Additional operations can be moved to a separate function and called in each branch.

Z: Removing additional operations into a separate function will reduce the speed of the program, and in some cases this is unacceptable.

P: A separate function can be designed as an inline-function, then this will not affect the performance in any way.

W:But then the program will take up more memory. And this, too, in some cases may be contrary to the task.

As a result of this dispute, termination procedures and a structural exception handling mechanism have been introduced in many languages. These tools work a little slower than GOTO, but are more visual, so for most tasks they are enough. But, again, there are tasks where it’s critical and this is “a bit” - in them the use of GOTO seems appropriate.

2. The principle of universal causality - if somewhere there is GOTO, then it is needed there.
A new language does not appear from floundering bay. Developers of programming languages ​​have a difficult task - to satisfy all the requests of programmers, and take into account generally accepted paradigms. It is absurd to assume that a concept will be implemented in the language that no one needs. If we take C as an example, then in general all questions disappear, because when analyzing the language, one gets the feeling that for each new operator introduced into the language, developers had to pay $ 5,000 out of their pocket ... but the GOTO operator is there.

3. Exiting multiple cycles at the same time.
P: The classic argument. You can’t argue against him.

4. Finite state machines (code example).
state_1:
	switch (signal)
	{
	case 1: goto state_5;
	case 2: goto state_10;
	case 3: goto state_8;
	}
state_2:
	switch (signal)
	{
	case 7: goto state_37;
	case 10: goto state_1;
	case 9: goto state_100;
	}

	// Достойных реализаций без GOTO не обнаружено.

5. Another example.
Sample Code ...
for (int i=0;i
inline void doSomeActivityInFor()
{
	for(int i=0;i


P: The code above runs at the same speed and takes up the same amount of memory as the code with GOTO.

Z: This example once again shows that you need to be more careful in developing the algorithm. The use of GOTO in programs is permissible, but it is not necessary to rush from one extreme to another.

To summarize


Crowds of religious fanatics by a team of skilled programmers often refuse the GOTO operator, even when its use is advisable from the point of view of the effectiveness and visibility of the program.

Bad tone in programming? If you take into account only the "tone of structuring", then yes. But there is still a “tone of speed" and a "tone of compactness", so you need to look for a compromise between them. [6] Programmers "working in the sandbox", as a rule, solve problems in which you do not have to think about saving resources, hence the misunderstanding.

It is also impossible to ignore the “structuring tone”, because In any case, the program will have to be finalized, and if it has an intricate structure, then unnecessary costs will arise. As in any other practical solutions, a compromise is optimal: the use of GOTO is allowed, but with the following reservations:

  1. You can only go forward.
  2. It is categorically impossible to enter blocks (either stay or exit).

Most likely, tales about the harmfulness of the GOTO operator were invented for novice programmers so that they would not use it during training. Students studying structural programming and language constructions at universities know that GOTO is evil. But when a specific task arises, one needs to proceed from it, and not from the templates that the programming language provides. It is rare that a practical pattern corresponds to a practical task. GOTO just helps to tailor existing templates to the task at hand.

Acknowledgments


I am grateful to the people who shared with me information and their thoughts about the justification for using the GOTO operator in the programs. Without your help, the article would express the one-sided opinion of a single person, i.e. me. Together with you, we managed to support a constructive dispute, as a result of which an unequivocal answer appeared on a topic that worries a large number of programmers.

Who are these people? Here they are:
I thank Dmitry Leonov for the creation of the bugtraq.ru website and for the fact that he managed to rally a large number of high-class specialists in his forum. It was on this forum that the most interesting discussion unfolded. I thank the people who took part in the discussion on this forum: I

thank OlegY, Heller, Zef for code examples where the use of GOTO is justified.

I thank HandleX for the philosophical thoughts about the need for GOTO in solving practical rather than theoretical problems.

Thanks to amirul for voicing the rules for using GOTO.

Thanks AMMOmium for the idea of ​​"horror stories" for beginners.

I thank the team of programmers from the codenet.ru forum for an illustrative example of a classic dispute, namely the following persons: nilbog, koderAlex, OlgaKr, kerdan, kosfiz3A3-968M, IL84, fanto, Sanila_san, nixus, green, newonder.

PS. Thanks for attention. I will be glad to comment; Questions and objections are also welcome.

Bibliography


  1. R. Linger, H. Mills, B. Witt. Theory and practice of structural programming. - M .: Mir, 1982.-406s.
  2. Edsger W. Dijkstra. Go To Statement Considered Harmful // Communications of the ACM 11, March 1968. 147-148.
  3. Niklaus Wirth. Good Ideas, through the Looking Glass // Computer, V. 39, No. 1, January 2006.
  4. Donald E. Knuth. Structured Programming with go to Statements // Computing Surveys, V.6, No.4. December 1974.
  5. Frederick Brooks. Mythical man-month or how software systems are created .: Per. from English - M.: Symbol-Plus, 2001.-304s.
  6. Karev A.A. Code # code .
Tags:

Also popular now: