Let’s look at some commonly used debugging strategies:
Visualize Your Data
The best way to understand what a code is doing or what a code is going to do, is to look at the data it is operating on. The simplest way is to use ‘variable name = value’ approach. But it will much more helpful if we use some debugging tools which help us to visualize data. There are debuggers that represent our data as 3D diagrams. Even if our debugger has limited capabilities for visualizing data, don’t go panic! We can do it by ourselves by using hand, pen and paper or by using some external tools.
Tracing
Debuggers allow us to check the current state of the program. But sometimes, we need more than that. What if we need to check the state of the program or a data structure for over a period of time? That’s when we use tracing codes.
Tracers are simple, primitive statements that we write into our code or file. It could be messages like ‘reached here’ or ‘value of x = 2’. Even though it looks simpler, it is particularly effective and important at many places.
Tracing statements can be used to "drill down" into the code.
Rubber Ducking
One of the simplest ways to find a cause for the problem is to explain the same to somebody. The other person may not have to do anything. Just listen and nod (like a rubber duck bobbing up and down in a bathtub). While explaining things step by step, we will be able to find the cause by ourself.
Verbalizing some of the assumptions we took always helps us to get new insights about the problem.
Process of Elimination
We might be working on a mixture of application code, written by us, written by others, third party products like database etc and the platform environment like OS and system libraries. It is possible that there exists a bug in OS, compiler or library. But that should not be our first thought when a problem is detected. It could be the code under development. Sometimes it happens because the application code is incorrectly calling the library. Even if the problem does lie with a third party, we'll still have to eliminate our code before submitting the bug report.
Eliminate the correct parts one by one and narrow down the domain. Finally we will be able to track down the real culprit.
- summary of Debugging, from The Pragmatic Programmer: from Journeyman to Master
Visualize Your Data
The best way to understand what a code is doing or what a code is going to do, is to look at the data it is operating on. The simplest way is to use ‘variable name = value’ approach. But it will much more helpful if we use some debugging tools which help us to visualize data. There are debuggers that represent our data as 3D diagrams. Even if our debugger has limited capabilities for visualizing data, don’t go panic! We can do it by ourselves by using hand, pen and paper or by using some external tools.
Tracing
Debuggers allow us to check the current state of the program. But sometimes, we need more than that. What if we need to check the state of the program or a data structure for over a period of time? That’s when we use tracing codes.
Tracers are simple, primitive statements that we write into our code or file. It could be messages like ‘reached here’ or ‘value of x = 2’. Even though it looks simpler, it is particularly effective and important at many places.
Tracing statements can be used to "drill down" into the code.
Rubber Ducking
One of the simplest ways to find a cause for the problem is to explain the same to somebody. The other person may not have to do anything. Just listen and nod (like a rubber duck bobbing up and down in a bathtub). While explaining things step by step, we will be able to find the cause by ourself.
Verbalizing some of the assumptions we took always helps us to get new insights about the problem.
Process of Elimination
We might be working on a mixture of application code, written by us, written by others, third party products like database etc and the platform environment like OS and system libraries. It is possible that there exists a bug in OS, compiler or library. But that should not be our first thought when a problem is detected. It could be the code under development. Sometimes it happens because the application code is incorrectly calling the library. Even if the problem does lie with a third party, we'll still have to eliminate our code before submitting the bug report.
Eliminate the correct parts one by one and narrow down the domain. Finally we will be able to track down the real culprit.
- summary of Debugging, from The Pragmatic Programmer: from Journeyman to Master
No comments:
Post a Comment