Page 1 of 1

Dealing with debugging and the learning curve?

Posted: September 28th, 2019, 4:07 pm
by orange3
So, a few days ago I was on lesson 3 and then had to stop, so I've basically forgotten whatever it was that I had done to cause this, but I was creating the const bool condit = wnd.kbd.KeyIsPressed(VK_UP); part. I try running it, and it immediately takes me to the main.cpp program with hundreds of errors. After what seemed to be an hour of going back and forth from the video, I'll likely have to reinstall and start over since with my skill level I can't even read what the errors are pointing towards to do anything helpful. But that's where a question came up out of frustration since "It was hard enough to make time out of my busy schedule and slowly making progress working on this and now because of this bug I have so start aaaaalll over" I wanted to ask the experience of other programmers when debugging drills a hole straight through what was already a slippery learning curve How did you deal with bugs as a beginner when everything is new, you barely grasp syntax and what it does, and nothing makes sense? While the obvious answer would be to try again, when I'm working on an hour of code each day slowly trying to make something despite time and it crumbles, it can get a bit demotivating, but it will be a while before I learn the skill of debugging and right now I'm just trying to write and learn things but..AAHHH. Sorry for the diatribe.
chilli lesson 3 error.PNG
chilli lesson 3 error.PNG (11.59 KiB) Viewed 2255 times
chilli lesson 3 error 2.PNG
(116.39 KiB) Not downloaded yet
here's the file if you want to try and fix it: https://ufile.io/4pwygcvd

Re: Dealing with debugging and the learning curve?

Posted: September 28th, 2019, 8:20 pm
by AleksiyCODE
Well, I might be able to help despite being a beginner myself.
First of all, you give a link to .sln file, but this file along is no use (try opening it yourself with Notepad and make sure that your code isn't there).
There is a page on Chilipedia on how to ask for coding help, so check that shit out https://wiki.planetchili.net/index.php/ ... ili_Forums
And secondly (i might be wrong), it seems there are no errors in your programm. You are just triggering a breakpoint (that red circle on the left of your code) (line 35 on your screenshot). Try removing it (and other circles if you have them) by clicking it.

Re: Dealing with debugging and the learning curve?

Posted: October 1st, 2019, 10:42 am
by chili
Yup, you clacked the wrong place and set up a breakpoint by accident :D

If you're really buttfucked over this one, just skip over to Tutorial 7 and you'll learn about what this shit is all about.

Re: Dealing with debugging and the learning curve?

Posted: October 4th, 2019, 5:50 am
by albinopapa
To answer the other part of your question, about how to deal with the frustration or how to deal with getting lost in code, I had the same thoughts but with a lot more time on my hands than an hour a day.

My advice is to step through the code ( press F11 to go line by line ). Think about what you want to happen, what code you did you write and as you step through the code, you might figure out where the problem lies. If it only happens during certain conditions, then there is a lot more work to be done, but one of the tools I found useful besides stepping through the code is the call stack. The call stack is a list of functions that have been called. The program starts in wWinMain, then goes to Game::Go and so on. The reason I find this tool helpful is because it allows you to rewind a few functions and inspect the values of things so you can hopefully catch where the problem began.

Now, how I dealt with it? Test your code often. After struggling with what I thought were insane bugs at the time, I decided to change how I did things. Work on a function, run the program, work on a function, run the program. This does two things. 1) Checks syntax and other language rules, this is known as compile time checking. 2) If it compiles, run it. Make sure that the new function is being called somewhere and test if it works under different conditions. This allows you to make sure the code is working as expected ( this is kind of like Test Driven Development or TDD, but less involved ).

On a side note, true TDD would want you to create a test suite for each feature of your program separately from the actual program. So for instance, if you wanted to draw a rectangle on screen, think of how you want it to work given the proper inputs ( position, size, color )

Code: Select all

//rectangle:  position = 390, 290; size = 30, 20; color = Colors::Green
void Graphics::DrawRectangle( int X, int Y, int Width, int Height, Color color )
{
   // A rectangle can be drawn by sweeping from left to right and top to bottom starting from 
   // X and Y passed in
   for( int y = Y; y < Height; ++y )
   {
      for( int x = X; x < Width; ++x )
      {
         PutPixel( x, y, color );
      }
   }
}
Now, try thinking about all possible values X, Y, Width and Height could be. Here, all the parameters, with the exception of Color are ints. Variables of type int can range from -2^32 to 2^32-1. X and Y represent the screen coordinates, so they can only go from 0 to Graphics::ScreenWidth or 0 to Graphics::ScreenHeight. If say X was negative, the program will crash in the PutPixel function because of the assertion made in that function.

Assertions are quite handy for catching silly mistakes. You can make your own assertion statement by writing: assert( some condition you want to be true );
So for instance, if you want the program to crash if you try drawing outside the screen coordinates, you could write:

Code: Select all

void Graphics::DrawRectangle( int X, int Y, int Width, int Height, Color color )
{
   assert( X >= 0 ) // Assert that X is greater than or equal to 0
   assert( Y >= 0 ) // Assert that Y is greater than or equal to 0
   assert( X < ScreenWidth ) // Assert that X is NOT greater than or equal to ScreenWidth
   assert( Y < ScreenHeight ) // Assert that Y is NOT greater than or equal to ScreenHeight

   for( int y = Y; y < Height; ++y )
   {
      for( int x = X; x < Width; ++x )
      {
         PutPixel( x, y, color );
      }
   }
}
One of the nice things about assertions is it only runs during Debug builds, so if all runs well in Debug and you have your asserts in place then you shouldn't haven't any problems in Release and you won't be penalized in performance for doing "sanity" checks. This also allows you to use the call stack if something does trigger one of the assertions. So if X is negative, then you click on the function before this one and see how it came to be negative.

Bottom line, don't lose hope. Learn the tools you are using on top of the language ( C++ ) and some other cool things master chili will teach and you'll get there eventually. Learning to code could be as quick as 4-5 months like Yumtard or 4-5 years like me lol.