As a programmer, we like it when our code works the first time. This hardly ever happens in reality. Most of the time, it runs well, but doesn’t give the output we expect. This is when we need to do some debugging. Let’s have a look at some debugging tips that can rapidly improve your programming efficiency.
Use The Output Command
One of the best ways to work out where a problem is in your code is to use the built-in command that outputs text. Many languages have this function, which takes a parameter and writes the output to a special window within the IDE. Some of these commands for various languages are:
- Java – system.out.println
- VB.Net – console.writeline
- PL/SQL – dbms_output.put_line
- Javascript – document.write
- Python – print
- PHP – print
This functionality is one of the first things we learn when learning a new programming language, and it can be used to display all kinds of information to help you find out what the issue is. The most common method for these functions in debugging is by outputting variable values. This is good for seeing what a particular value is when the function is called. However, it’s not always the best way to find the cause of the problem.
Some other debugging tips for the output functionality for include:
- Writing out both the variable name and the value, such as “stringFirstName: Johathan”, so you can see the variable name and the value.
- Markers in the code, so you can see where the code went. You could use the function name or an abbreviation with a number, such as “loadName 001″ then “loadName 002″ at a different point slightly later in the code. If you see the first but not the second, you know that the code did not follow that path.
- Timing the code. You can set up a timer variable to see how certain parts of the code perform, and also to see where the errors are. If a piece of code is expected to run in 2 seconds, but you find it takes 10, then you can see where the problem is.
Set Smart Breakpoints
Breakpoints are a fantastic feature. A breakpoint is a feature in an IDE that allows you to indicate a line of code that the execution should pause at when it reaches. I’ve seen this use quite commonly by software developers.
However, there are good and not so good ways of using the breakpoint.
Breakpoints should be used to return to a place in the code that is near where you are investigating. It’s used to save time with debugging – instead of stepping through many lines of code to get to where you need to be, you can go there instantly with a breakpoint.
Remember this when you set a breakpoint. Set it to as late as you can just before where you’re investigating. Don’t set it too early, as you’ll just waste time skipping through functions and code that you don’t need to look at. If you need to verify that certain paths in the code were taken, then use the output tip mentioned above – it’s heaps faster.
Use Watch Variables with Triggers
Watch variables is another one on the list of debugging tips which can help you debug faster. A watch variable is where you set a particular variable to be “watched”, which means its name and value are shown in a window within the IDE, so you can see what it’s set to at any point in time. This is great to see how values are changing and what variables are set to when your code breaks.
Be careful of the scope of variables. Most IDEs let you set the scope of the variable to watch. This can be a problem if you’ve got the same variable in a higher scope, which can confuse you if you’re expecting something else.
Also, you can sometimes set triggers with watch variables, which is a great piece of functionality. This means that instead of just watching a variable, you can set a trigger on it, so that when the variable meets a certain condition, the code stops. This is a massive time saver for code with loops.
For example, let’s say you think your code is failing because a certain variable is set to an empty string which breaks further down the line. You can set the trigger so that the code stops if this variable is empty. When it is empty, it stops the moment that it happens, so you can see why. You can then set a breakpoint for further investigation.
Also, you can set them inside loops. Let’s say you think your code is failing because your loop iteration number is too high. You set a watch value on this (loopCounter >= 999, for example), so the code stops. You can step through the code to see if this is the issue.
These first three debugging tips all involve using the IDE, which is one of the best tools you can use as a software developer.
Watch Out for Extra Characters
A seemingly small problem, but can cause a lot of headaches, is when values look like they are OK but actually include extra characters. If you’re outputting variables, or watching them, then it might look OK to the naked eye, but in reality they have other characters inside them which is causing problems. This could be:
- Extra spaces, on the end of values or on the start (this is a very common one I’ve found)
- Non-printable characters, such as newlines
- Punctuation (commas, full stops, quotes)
- Other syntax which is not needed, such as HTML tags in your variables
These little things can cause all kinds of problems if not done correctly. Keep an eye out for them when you’re debugging.
Be Careful of Data Types
Sometimes I’ve found that while values look OK when debugging, it’s the data type that causes issues. This isn’t immediately obvious, as I’m usually focused on the values and where the code is at.
However, it’s important to check the type of the data as well. Sometimes, functions expect floats but are passed integers. Sometimes a string is expected but a number is passed. Sometimes the conversion is supposed to happen, but it doesn’t.
You can check the types of the variables using a few methods, depending on your IDE:
- Hover over the variable name, which often shows the name, type and value.
- Check the watched variables window, sometimes this shows the type
- Output the variable type in the output window, using the method above.
Try Outrageous Inputs
Another way to check that something is working as expected is to try to purposely break it. In many cases you can set the input values or change existing ones for functions that you’re debugging.
One thing I try to do is set the input values to something totally outrageous and unexpected. This isn’t just make up funny words, but I mean give it some values it’s not expecting:
- Very long input fields – if it’s normally 50 characters, try 200
- Empty input fields
- Extra large files, if you’re working with file inputs
- Extra large or small numbers
It might not be valid for your scenario or your program, but using this technique can help you find out if something strange is happening.
If All Else Fails, Use Google For Debugging Tips
If you’ve tried the debugging tips in this article, done your own debugging, and still can’t find the issue, I’ve got one more tip.
Google.
Many times I’ve been unable to find the solution to a problem, and I’ve gone to search for it on Google and found the answer. Sometimes the answer is shown easily and at the top of the search results, sometimes it takes some digging through forum posts and code samples.
Try to search for the issue you’re having, using words that others are likely to use and are specific. A search term such as “java file import error” may not be as effective as “java file import causing GUI crash”, as the second phrase is more specific to the issue you’re having.
A lot of sites specialise in finding and solving people’s questions on code, and one of the best ones out there is StackOverflow. I’ve used this many times to help me fix problems. It’s a fantastic site.
If it doesn’t give me the answer I need, it often gives me ideas on what the cause could be and other debugging tips.
I hope these debugging tips have helped you with your programming. Do you have any other tips that you use? Share them in the comments below.