Whether you are a programmer or a project manager, “program bugs” throb you the most. As said that – “A running program is the most illusive piece of beauty”, but it take lots of effort before we get that going.

Bugs are true show stoppers. As someone said that – “To err is human, to debug is divine”. In this article I will try to put the best practices that can be used to debug. These practices are helpful to programmers as well as other administrator who write SQL Queries and Shell Scripts.

What is debugging
In any program, errors can be of two types – Logical Errors (semantics) and Syntax error. It is easy to trap and resolve syntactical errors as the compiler or language helps you in that, but it is very hard to trap logical errors. Debugging is a process of trapping and resolving both logical and syntactical errors.

Process of Debugging
Debugging can have two directions, these are – steps when cause is identified and when cause is only suspected. We take different steps in both directions.

1. When Cause is only suspected – We need to perform some additional test. This will change the status of suspected cause to identified cause or not a cause at all. If this happens we can go for the following step.

2. When cause is identified – If the cause is identified, now its time to correct the cause. This is important to note that sometimes even an identified cause can be unable to debug the problem. In such cases we have to search further.

Best Practices
The process of debugging is quite simple and obvious, but our aim is not to get obvious methods, but to search best practices for fast debugging. Some suggested techniques can be –

1. Think out of the box – this scheme is very useful when you are trying to debug our own program and that – all alone. What generally happens, you presumably think that the code is error free and logic has no flaws, but most of the time, you are wrong. Just try to read each code line and presume that it is wrong, this way you can quickly grab some errors.

2. Dry run – our C/C++ teacher Mr. Arun was found of dry running, in his words “Imitate the compiler, then automatically you will produce errors”. The logic behind dry run is simple, take a piece of paper and execute the whole code line by line. In the mean while make sure you write all modifications in the variable value. You can catch many bugs generated only due to change in values. This is also called walk through.

3. Bug patterns – “bugs lurk at boundaries”, it is proven fact that bugs basically come at the boundary values. Programmers have a tendency to misuse less than equal to or greater than equal to. This leads to error. Always make sure that your logic is not failing at the boundary values.

4. Add more debugger – try to add some of your friends in the debugging process. Sometimes when you are stuck at some point, a person who is not related to your code can easily take you out of the swamp.

5. Follow the traces – In programming, my first love is Basic (from GWBASIC to VB.net), I use trace on feature, in which all the lines of code are executed on by one and all changes are shown. Try to use some debugging tool are adding some extra code to alert you all changes. This is certainly help.

6. Track changes carefully – Sometimes, when you are debugging any code and you are not sure what exactly the problem is, then you can forward in wrong direction, and in course of that make changes in the codes. These changes do not help in debugging, though they can add some more errors. Make sure that you use some method to track your changes, so that, you can easily undo them. One of the methods used can be saving the program with different names.

These best practices are not ultimate and also not sufficient; one has to put “the extra” in debugging. And this extra depends on you only.

Check List to execute it in fists run

1. Check all variables are declared before use.
2. Datatype conversions are done according to rule.
3. Operator precedence is followed.
4. All functions and operators are provided with complete parameters.
5. All functions, which are called are declared or linked.
6. If the language supports “:=” or “==” as equal to operator, “=” is not used by mistake.
7. Boundary values of all loops and recursion are handled carefully and they are correct.
8. All loops and recursions are terminated.
9. Commenting is done.
10. In finalizing any code, make sure that all check points kept as debugging are removed.

Following these checklists will help in tracking out some of the basic errors, which can lead to confusion.

Conclusion

Debugging, in my opinion, is middle phase between full fledge testing and coding. Debugging is chiefly done by the programmer. If carefully done, it can eliminate any possibility of small errors found in the code. In my opinion bugs are show stopper and you need to remove them before getting in next phase of your programming. A good software programmer is one who is also good debugger.

Manu Dutt Tripathi is a young energetic computer professional working as a consultant DBA in leading IT firm of Bangalore, India. He has a master degree in computer science. He is an active member of many technical forums and help users and computer professional through out the world.

More such ideas can be found at http://manudutt.wikispaces.com.

Article Source: http://EzineArticles.com/