How to use Debug Tools [Part 1]

The king of debugging

You know him, everybody does.

print("I am here")

Isn’t he great? He never let you down when you needed him, he never failed. Unfortunately, he has one big problem, he wastes your most valuable resource. Time

But, what do you mean?

Imagine being a line painter on a highway, your job is to paint lines across the highway. You have a variety of options to accomplish your task. You’ve started. First 10 meters were easy you just soaked the brush in the paint and started painting, first meter, second, third and you ran out of paint, so you came back to bucket with paint and again soaked the brush in it, you came back to the point where you finished. fourth, fifth, sixth meter and so on. After twenty times walking back and forth you started to feel tired.

This is when you are printing in your code. You will eventually find the issue, but it will cost you more effort and time.

Debugging tools

Most of the IDEs and great text editors have debugging tools. If yours don’t, you should switch it then.

Breakpoints

Probably the best debugging feature ever made.

Let’s show it in practice. We want to write a program that makes three steps forward (in a strange way). This is the code with a bug. I’ll be using C#.

static int MakeThreeStepsForward(int currentStep)
        {
            int newSteps = currentStep - 2;
            newSteps = newSteps + 5;
            newSteps++;
            return newSteps;
        }

Can you spot the bug? Of course, you can because it is a super easy example. But let’s say you don’t. So what would be the first thing you would do? Print statements (Console.WriteLine() in C#). Let’s try that for currentStep = 2

 static int MakeThreeStepsForward(int currentStep)
        {
            Console.WriteLine(currentStep);
            int newSteps = currentStep - 2;
            Console.WriteLine(newSteps);
            newSteps = newSteps + 5;
            Console.WriteLine(newSteps);
            newSteps++;
            Console.WriteLine(newSteps);
            return newSteps;
        }

The output of the program is 6, expected is 5. And there are our prints

This is not very readable, isn’t it? At this point, you start analyzing console output with the code. All right the bug can be fixed in the first line, there can be -3 instead of -2. It still isn’t hard, but this is “alghoritm” that has 4 lines of code. Imagine doing so in 40 places in your code. It would be a nightmare.

Now let’s jump to example with breakpoints

Breakpoints are stopping the program at the beginning of the line, not the end!

By creating a breakpoint on second line program stopped, showed values and you could inspect every value in the current context, you can check out everything just by creating one red dot! No more prints!

Remember our highway painter? He found a perfect solution on how to speed up his job, he started taking the bucket with paint with him! No more going back and forth. This is when you use breakpoints.

More tools

Every IDE or text editor that supports debugging has a lot more debugging tools, conditional breakpoints, function breakpoints, call stack, live watches and more! You should definitely check out what your editor has and not be afraid of them! This is key to fast and efficient development.

Debugging friendly editors

Most of the IDEs have great debugging tools, but not all the text editors. Personally, the best text editor for a programmer is a Visual Studio Code, it has a huge amount of community extensions, it is fast, and has great debugging tools!

Conclusion

I was surprised that my friend who is definitely not a beginner programmer still uses prints instead of proper debugging tools, they are not decorations, use them! Sit for 30 minutes and try what they can do, you’ll thank yourself later. Also, I’ll write about using some debug tools in detail. It was an introduction to the idea of debugging.

Update 1

It’s worth to notice that there are some cases where using print is fine.

My first open source project

Introduction

I’ve started building my first open source project back in November 2017. I actually thought to write it for fun, I didn’t know that I’ll be extending this idea, It was supposed to be a 30 min project. But many ideas came to my mind and this is how it’s started. Also, Pixi (this is how I named it) was a closed-source at first.

Heavy Squares.

When I was learning Microsoft’s GUI Framework called WPF I decided to make a very simple program to color pixels on click. Yes. Something very similar to MS Paint, but on a smaller scale, like a 3×3 grid. This idea came to me when I was reading about rectangles from WPF’s toolbox. Young stupid me thought “What if I’ll connect 9 rectangles and color them on click”. I quickly started to construct my brilliant idea. It was working. I can even say, that it was working perfectly. But don’t forget that it was just 9 rectangles. I saw potential in this project, so I started expanding it. This is when It’s getting funny, when canvas with squares began to be bigger (1024×1024 for instance) program was eating resources like stupid. A huge amount of ram (about 3 GB) just to create a 1024×1024 grid with squares. And of course, the code was messy too.

Refactoring

I started having troubles in understanding what was going on in the code. It was caused by my unconcern. Quality of code caused my fear to do any changes, so I stopped working on Pixi for half a year. After that time I got motivated again, and I started refactoring the code. In fact it wasn’t refactoring, it was rewriting program from scratch. I took me about a month to finish rewriting it, I’ll write more about refactoring in other post.

Current state

After successful refactoring, I decided to publish PixiEditor to github. You can contribute, download and modify the code. First usable version is available on releases page. Stay tuned!

Screenshot from first release of program

My first game

How it started

As I mentioned in My programming story I made a game. Bad one of course, but from scratch, by myself. And it was a HUGE milestone to me. It was the time when I stopped copying the code from videos/articles and built something mine. It’s worth to notice that I was 13 years old while building this game.

What was it about?

It is a labyrinth game called Potato Labyrinth, where you move a guy that is a potato (literally) to find a way to the exit. But it isn’t all. There are “fancy” mechanics in it, like portals, gates and I even made a dark level, where you only can see a few meters away.

Building

I made this game using Unity game engine and C# programming language, It’s a really powerful piece of software. Here is a short snippet of the game code that is responsible for the pause menu:

public class PauseMenu : MonoBehaviour {
    public GameObject pauseMenu;
    public static bool pauseMenuActive = false;
    // Use this for initialization
    void Start()
    {
        pauseMenu.SetActive(false);
    }

    // Update is called once per frame
    void Update()
    {
        if (Input.GetKeyUp(KeyCode.Escape)&&pauseMenuActive == false)
        {
            pauseMenu.SetActive(true);
            pauseMenuActive = true;
        }
        else if (Input.GetKeyUp(KeyCode.Escape)&&pauseMenuActive==true)
        {
            pauseMenu.SetActive(false);
            pauseMenuActive = false;
        }    
    }
   public void BackToMenu()
    {
        SceneManager.LoadScene("Menu");
        Points.points = 0;
        LevelPointsRequired.activelvl = 1;
        pauseMenuActive = false;

    }
}

The code is terrible, as you can see, but it was my first true creation.

Summary

My first game was a bad one, but that’s okay! Everybody has to start somewhere, even a bad game like that is the next step for something better, bigger and more ambitious. I’ve decided to share this game if you want to check it out here.