The program code may not always be written correctly. When there is no expected result, we often can’t figure out the reason. At this time, we need to debug the program to locate the error.

In the early days, the primitive debugging method was to output the intermediate results of the program to see which step was wrong. The development environment of modern programming language basically provides perfect debugging function, which can execute code step by step to see whether the direction of the program is consistent with the expectation, and whether the intermediate results are consistent with the expectation.

esProc also provides these functions, all on the program menu. It’s difficult to describe the use of debugging functions in words. You can find it out quickly after trying several times. We won’t elaborate here. SPL codes are written in the cells, and each execution unit is a cell. It’s easy to check the value of cells and variables midway, and it’s naturally very convenient for debugging.

Now that we have learned the branching structure, the program is no longer always going from top to bottom. It may go through different paths under different data. You can use the program debugging function to observe the direction of the above programs.

In the process of debugging, sometimes we want to see the running effect when a piece of code is skipped and not executed. However, if we delete this code, we may need to add it back later, which is troublesome.

In this case, comments can be used. Almost all programming languages provide comment statements or functions. In SPL, if a cell starts with /, it is considered as a comment cell. This cell will be automatically ignored and skipped during execution. If a cell starts with //, the cell and its code block will be ignored and skipped.

You can try to add / or // to some cells to see what changes will occur in the code display.

In the following code, A7:D7 and D5 will be ignored and skipped, that is, the second solution will not be calculated, and the case that B1 is not 0 will not be handled.

It’s very convenient to use comments to control debugging. You can change this code into comments when you don’t need to execute it, and change it back when you need to execute it again. The main body of the code doesn’t need to be deleted.

The original intention of the invention of comments is to enable programmers to write some code related notes in case they can’t understand the code after a long time. Of course, this role still exists, good program codes always have detailed and clear comments. In SPL, the text written directly will be regarded as a constant cell, which does not affect the execution of the program. It can play the role of comments, and the role of a comment cell is more used to facilitate debugging.

if statement can change the direction of the program, many programming languages also provide a more simple and crude way to change the program flow, that is, goto statement. Let’s rewrite the code of solving quadratic equation to feel it (only consider the case that A1 is not 0):

There is an extra empty line in the code, but the logic seems very clear, avoiding the long if… else block.

A more complete case can also be rewritten with goto:

The goto statement has been controversial since it came into being. Many computer scientists complain that it can mess up the flow of programs. When a program is running normally, we don’t know what will happen when a goto statement appears, and it is very difficult to debug when the program goes wrong. Therefore, some programming languages simply do not provide goto statement, and do not allow casual jumping.

However, sometimes when the program level is deep, when the conditions are appropriate, jumping out with a goto statement will make the code clearer. If goto is not used, it is likely to make repeated judgments to avoid executing statements that should not be executed. Our attitude towards goto should be: don’t ban it, but use it carefully. Generally speaking, we can keep this principle: always jump out from the depth of multi-layer code (for example, SPL code blocks have obvious levels), not jump in; Jump forward, not backward (though not forbidden).

goto is always userd with if, that is, jump when a condition holds (or does not hold). goto, when it has nothing to do with if, is meaningless. Jumping forward will make the code in the middle useless (instead, it can be used for debugging, playing the role of comments mentioned earlier); Jump backward and the program will never end.

However, in SPL, if you accidentally write a program that will not end, don’t worry. When the code is running, the development environment is not dead. You can use the debugging function to terminate the program.

SPL Programming - Preface
SPL Programming - 2.2 [Doing judgement] Branching structure
SPL Programming - 3.1 [Doing loop] Single layer loop