As our applications grow, we'll run into more complex bugs. Fortunately, there are multiple tools, techniques and approaches to quickly locate and squash pesky bugs.
C# offers lots of information when we encounter an error. Errors are there to give clues. They might not tell us exactly what's wrong with our code but they usually point us in the right direction.
The first step in debugging should always be to follow the errors. Check the line number that the error references as well as the lines directly before and after the error. So much of programming is about pattern recognition, which is why stylistic things like indentation are important. As we get used to the way clean code looks, more mistakes will be visually obvious and easier to debug.
Sometimes code won't execute as expected and there isn't a detailed error. If this happens, don't panic! Again, it's important to accept that encountering bugs is just part of programming. Here's a few of the most common methods for debugging.
It's easy to get lost when debugging if we don't keep track of what we've tried already.
As we debug, it's important to write down what we try and what the result is. This keeps track of the clues we uncover while we're troubleshooting. It also makes it easier to explain a problem to someone else. If other developers can see what we've tried so far, they can better understand the issue at hand. Instead of simply saying "my code isn't working," we can say something like "My code isn't working and I've tried X and Y."
Organization is key - we don't want to be running in circles trying the same things over and over. We also want to be able to succinctly communicate our issues and troubleshooting attempts to other developers.
We can use
Console.WriteLine() to print the value of variables, what a method is returning, and so on. In fact, we can use
Console.WriteLine() just as we use
Another good way to diagnose what's wrong with our code is to debug it one section at a time. Comment out everything in a problematic area of code. Then uncomment out code line by line, seeing what works and what doesn't. This can help determine exactly which line caused the issue.
Also, regular commits can help us with debugging. We should commit whenever we make working updates. That way, when our code breaks and we can't find a way out, we can revert to a previous commit. We can check our previous revisions on GitHub by clicking on Commits in the top left corner of a repo.
We can also revert our code to a previous commit by running the following series of commands:
$ git log --oneline
This will list all of our local Git commits. Locate the number of the commit to revert back to and save it.
Then, run the following command, providing the specific commit number:
$ git reset <commit-number>
For example, if a commit had the identifier
56e05fced, we would revert back to that point in time with the following command:
$ git reset 56e05fced
Google is a fantastic tool but should be used with caution. Look at message boards like Stack Overflow to see if others have encountered a similar problem. However, when using someone else's code, it's essential to understand exactly what it does. Blindly copying and pasting code because "it just works" will only create headaches later.
Sometimes it's necessary to take a break and step away from our code, especially if we find ourselves getting angry or frustrated. Take a walk or have a snack. Stepping away from a problem can also indirectly - or even directly - lead to a solution. This is in part because our brains often continue to mull over the problem in a subconscious, decentralized way, which might be just what we need to attack the issue from a different angle.
Step through code line by line from beginning to end. It can help to say the code out loud or even write it down. Try testing code in a REPL, check the value of variables and so on. Simplify everything. Check code that is assumed to be working - we might have accidentally introduced a bug or there could be another unintended effect of that code we haven't considered.
For example, maybe nothing is working because we've been editing the wrong copy of the file. We have seen this happen many times to students!
Ask a classmate to take a look. Sometimes a different pair of eyes can spot something simple like a spelling error. In fact, frequently, just the act of explaining a problem to someone can be enough to help figure out a solution.
Document all bugs and their solutions. We should discuss the solution with our pair and ask ourselves the following questions: "How will I prevent this problem from happening again? What error messages should I watch for? If I see the error again, where should I look for a solution?" This will help save time so we can learn from our mistakes. Embrace bugs as an opportunity to learn programming more deeply and to avoid future bugs.
Lesson 5 of 5
Last updated more than 3 months ago.