You’re updating an old method by adding only two simple lines of code at the end, but something is really wrong here. You checked all the method calls and parameters that you’re passing, but they are correct. So maybe their values are incorrect? You run a debugger and check. Nope, they are perfectly fine. The problem might be in the function itself, but it worked like a charm until now, so you’re rechecking your two lines and you still cannot see any issues. Continue reading “Short #2 Leave these parameters alone”
I mean, what’s the point? Let the code flow naturally after the ‘if’ and leave more unlikely situations for ‘else’ (displaying error for instance). In the ‘if’ block, you can put cases that are more natural for your game. A player wants to deal damage to living enemies. It is more common, as dead bodies are usually waiting for being cleaned up and are less attractive for the player. So: Continue reading “Short #1 Don’t stick to ‘no negations in conditions’ rule”
In an ideal world, we write bug-free code. In the same universe, we don’t have to struggle with marketing our indie games, and we are skilled in design, programming, graphics and audio. Today I’ll try to make fixing bugs easier and faster for you, so you’ll have more time for more enjoyable tasks. Welcome to the second part of the series about making debugging an (almost) pleasant experience for you.
Fixing bugs is difficult enough. You don’t want to add ‘What the fuck is this shit’ on top of that. In the previous post – 7 good code practices that will help you in debugging – we tried to get rid of those unpleasant thoughts, so in this one, we’ll be dealing with a pure puzzle solving. That is because bug happens. So let’s get into it.
Hey guys! Welcome in the first post in a series about debugging process. This post will be treating about good practices which will help you in the debugging (and/or decrease amount of situations where you’ll need to do that). The second one will be about debugging process workflow, tools and how to use them in Visual Studio. I will focus on the most useful ones in my opinion. After these two posts, you should be equipped with a set of tools that, I think, are enough in most cases. This article collects code practices that are good in general, so even if you think you don’t need debugging (yet), you will make use of them. I decided to write this short series for two reasons. The good practices are good not because the big individuals said so. They are good for a reason. They make our development lives easier. I want to show you their usefulness during the debugging process because debugging is a reasoning about the code. It requires a lot of focus from us. This is a situation where code quality makes a huge difference. These practices make that reasoning easier. The second reason is that I see too many ‘easy’ questions on the Stack Overflow, Quora, and Facebook groups. By ‘easy’ I mean the problems that are fairly simple to solve during the debugging process. It seems like many of us just don’t debug at all. Maybe because they just don’t know how or it seems too hard or time-consuming. They prefer to delegate the problem to the Internet, what is usually more time consuming than debugging it by themselves. And the truth is, after fair amount of practice, you can find it almost easy and almost mechanical. No matter how good your code is, the bugs will happen sooner or later. You will have to get to the source of the problem. This is where the debugging begins and you better be prepared for that. Let’s get into it!