September 19, 2017 Debugging For Marathon Competitions

Some top competitors in the Marathon match competitions prefer not to rely on the tools when it comes to locating and fixing bugs in the code. For instance, Psyho and wleite use no tools. This methodology has some major bonuses: it trains short and long-time memory, mobilizes mental forces to concentrate on the code one writes, to name a few. However, in order to use it successfully the initial level of the mentioned skills is too high. The programmer needs to have exceptionally good memory and concentration.
In the industrial programming, on the other side, you can seldom find a developer who does not use any IDE tools. It is hard to tell if this is because industrial programmers have not so nice memory and concentration, or the relationship is the opposite and their memory and concentration worsens because they use the tools. I prefer to think that it is the former case, but I have no proof.
The objective of this article is not to give a detailed explanation of each and every possibility of the IDE. Instead I will just point the minimum set that I find necessary for competitions.

The Debugger

The subjects I will discuss here might be trivial for those who know them, so feel free to finish reading as soon as you fall asleep.
The debugger is a tool that allows you to execute the code in slow motion. You can run it line-by-line, and investigate values of all the variables you have.
Each IDE has its own naming and placement for the debugging-related commands. In order to use your IDE of choice effectively, you have to know the following as a bare minimum: Step Over, Step Into, Step Out, Continue and Pause.
The Pause command allows you to suspend execution of your program and investigate what is wrong with it. It comes useful when you have something like an infinite loop.
The normal flow of debugging a program that does not work as expected is as follows:

• Put a breakpoint in the very beginning of the program’s main function.
• Launch a debugger.
• Step over most of the lines.
• Investigate the variable/watch values.
• Find a function that does not work as expected.
• Drag execution cursor back to the line where program still behaved normally.
• Step into function(s) that did not work as expected.
• Locate a bug.
• Change the line(s) that caused the bug.
• Optionally restart the debugger.
• Start from the top of this list.

There are some issues with this list, though. Most of the IDEs do not support altering the order of execution. One famous exception is Visual Studio that allows you to alter the order of statements by drag-and-drop of the yellow arrow.
Another issue is that not every IDE supports hot recompilation of the code. You may need to stop the debugger, then fix the bug, and start over again.

Debugging For Marathon

Usually Marathon matches come with a Java-based offline tester. If you write your solution in Java, you are lucky and can just integrate a call to your solution into the tester. It will be possible to debug the solution after that.
If you write in a different language (here I will assume it is C++), debugging is a little more tricky. One possible workaround is to write your own tester in C++, and integrate it into the solution. This is time consuming and boring. I never did it.
Fortunately, there is a magic button “Attach to process” in many IDEs. Check if yours has one. The idea is to launch the solution through the visualizer, and then attach the IDE to its process. To do this, you need to compile the solution passed to the visualizer with the same compiler as your IDE uses. However, the solution most probably will finish before you will attach the debugger to it. I solve this by adding a “new Scanner(System.in).nextLine();” statement into the visualizer source code before it starts doing the IO with the solution’s executable.

Alternatives

There is only one way to find and fix defects in the code if you prefer not to use an IDE. It is printing into the console out. The biggest drawback of it is that you have to know beforehand what to print there. This is usually non-trivial to determine.
One good thing about it is that you can combine printing to the console with the traditional IDE debugging possibilities.

Conclusion

It is up to you to decide if you need the debugger for the Topcoder. I cannot imagine what I would do without it. Even if your skills are excellent, you may need one just to speed up the problem solving process. The programming is much less stressful and more fun with the debugger as well.