Suggestions on debugging methods in the informatics competition, and debugging of the Informatics Competition

[Switch] suggestions on debugging methods in the informatics competition, and debugging of the Informatics Competition

The difference between Informatics and other competition disciplines lies in the need to write programs to express their own thoughts and ideas. How to debug programs as quickly and well as possible has become a problem that we must think about. I believe many of you have had this experience: it takes only half an hour to think about an algorithm, but it takes a day to write this algorithm .. Thinking and implementation time are often not proportional.

The following are some small suggestions I have provided based on my own experience. They are for your reference only. If you have any bad ideas, please correct them ~

There is a major premise for debugging, that is, the direction of thinking must be rigorous and correct, because thinking Determines implementation. If there is a loophole in thinking, then the program to be implemented is certainly not strong. After coming up with an algorithm, do not rush to implement it. Be sure to make repeated arguments: is the definition of each step of my algorithm rigorous? Is there any vulnerability, does my algorithm obtain the question that needs to be solved. Confirm your ideas before implementation.

Suppose we have finished writing a program:

Step 1: static error detection (commonly known as naked eye observation ^_^), that is, the data is not tested, but the code is checked repeatedly. For static errors, you must first check whether the variable name is incorrect, whether the syntax is correct, and whether your code matches your idea. Then we need to analyze whether the logic of the Code is rigorous and correct, and whether the code can run correctly in all circumstances. Finally, verify whether all boundary conditions can be correctly resolved, including whether the array is open enough and whether n = 0 exists. Static error checking is the most effective method for checking errors. Why can some scalpers write complex code over and over again, because they have very powerful static error checking capabilities, in addition, static errors have been found during program hitting. In practice, I suggest you modularize your program as much as possible (that is, a function is used to do one thing), and then comment while checking, in this way, you can make a clearer judgment and easily read your programs in the future.

Step 2: Check the error dynamically and use data to verify the correctness of the Code. Human eyes are often unreliable, and we need to use safer data for determination. In general, there is plenty of time in the OI competition, and we have time for matching. Three procedures are required for upyun, one is the standard program (std) You need to submit, and the other is the violent Program (plain) that can pass part of the data ), one is a program (mk_data) used to generate data ).

The plain program is generally easy to write, so be sure to check carefully and do not make any mistakes!

For mk_data, a random integer is generally required. The c ++ language is written as follows:

We can run mk_data once to get a set of data, and then run it again with std and plain to see if the results are the same. Of course, manual operations are quite troublesome. We can use scripts to perform automatic Video Recording. Below is a common method of bat script for video recording in windows:

(The output file of plain is 1.outand that of std is 2.out)

Write this paragraph in a text file, rename it as ck. bat, and put it in the same folder as the above three programs. Double-click ck. bat to implement the matching. The advantage of the camera is that it can simulate the data of the person who asked the question to test your program. Generally, it is difficult to write the program through the camera in the test room. Of course, sometimes random data may not satisfy our needs. At this time, we need to construct some data in the worst case from the perspective of the person who asked the question, to test the robustness of our program.

Step 3: Check the file name, compile the program again, and run the sample again before submitting the application.

Static errors greatly reduce the probability of program errors, reduce the time required for dynamic debugging, enable double insurance for the Program for dynamic error detection, and finally prevent unexpected situations. The correctness of such programs can be greatly improved.

In debugging, the most critical point is to think about the program at the logic level, rather than viewing the variable from a data point of view, so as to avoid being stuck in the quagmire of debugging.