Whether you are a programmer or a project manager, "program bugs" throb you the most. As said that - "A running program is the most elusive piece of beauty", but it takes lots of effort before we get that going.
 |
| How to correct errors: best practices |
Bugs are true show-stoppers. As someone said - "If a person makes a mistake, then the correction 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 administrators who write SQL Queries and Shell Scripts.
how to, best practices, c# exception handling best practices, Wikipedia best practices, CSS best practices, how to catch errors in ssis, how to create a promise, how to catch an error in a promise.
What is debugging
In any program, errors can be of two types - Logical Errors (semantics) and Syntax errors. 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 the cause is identified and when the cause is only suspected. We take different steps in both directions.
1. When Cause is only suspected -
We need to perform some additional tests. This will change the status of the suspected cause to identified cause or not a cause at all. If this happens we can go for the following step.
2. When the cause is identified -
If the cause is identified, now it's 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.
how to handle errors in ssis, how to get better at CSS, and PHP best practices, how to set tile, java exception handling best practices, how to create custom decorators, and how to fix errors on Wikipedia.
Best Practices
The process of debugging is quite simple and obvious, but our aim is not to get obvious methods but to search for 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 your own program - 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 found dry running, in his words "Imitate the compiler, then automatically you will produce errors".
The logic behind the dry run is simple, take a piece of paper and execute the whole code line by line. In the meanwhile make sure you write all modifications in the variable value. You can catch many bugs generated only due to changes in values. This is also called a walkthrough.
3. Bug patterns - "bugs lurk at boundaries", it is a 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 errors. Always make sure that your logic is not failing at the boundary values.
4. Add more debuggers - 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 the feature, in which all the lines of code are executed one by one and all changes are shown. Try to use some debugging tools are adding some extra code to alert you of all changes. This is certainly helpful.
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 the 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" into debugging. And this extra depends on you only.
Check List to execute it in fists run
- Check all variables that are declared before use.
- Datatype conversions are done according to the rule.
- Operator precedence is followed.
- All functions and operators are provided with complete parameters.
- All functions, which are called are declared or linked.
- If the language supports ":=" or "==" as equal to the operator, "=" is not used by mistake.
- Boundary values of all loops and recursion are handled carefully and they are correct.
- All loops and recursions are terminated.
- Commenting is done.
- In finalizing any code, make sure that all checkpoints 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 the middle phase between full-fledged 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 a show stopper and you need to remove them before getting into the next phase of your programming. A good software programmer is one who is also a good debugger.
