How to reduce bugs while coding
1) Enable all of your compiler warnings.
This will help you to detect many of the potential bugs even before the code has started execution. In fact, it might be even better to set up your compiler so that it will include a warning as an error so that all warnings must be resolved for a successful compilation.
2) Use a static analysis tool.
A static analysis tool like ‘lint’ can help detect suspicious language usage. Suspicious usage includes: variables being used before being set, conditions that are constant, and calculations whose result is likely to be outside the range of values representable in the type used.
3) Writing robust, defensive code to prevent bugs.
Defensive coding helps in preventing a plethora of bugs that might occur due to garbage values present in variables. This holds true especially if variables have not been initialized and passed into functions. Having a strict check of what is allowed into a function goes a long way into prevention of potential bugs.
4) Debug through your code.
Perhaps one of the most important steps in an attempt to write bug free code is to always debug through your code instead of directly executing it. Stepping through your code is a form of self code review that will help you weed out a lot of potential problems that the developer would not notice just by a normal execution.
5) Using asserts in the debug version.
Usually, when developers work on a project, it is in debug mode. This mode supports debugging the source code by adding breakpoints. Also we could add asserts into the debug mode that would be disabled in the release version. But having asserts into the debug version, we ensure that all the possible bugs due to improper conditions in the source code will be caught before the release of the software.
6) Get a code review.
Code reviews of the software you write by your peers is a good way to detect potential bugs that may be in your programmer’s blind spot.
7) Using unit tests to find bugs.
Unit testing is a method of writing tests for each of your units (usually functions) to check the behavior of the functions when the inputs are of various types(correct, erroneous, upper/lower limits, etc).
8) Keep it simple.
Many programmers tend to write complex codes as they want to show off their coding skills. However each line of code that you write could be a potential bug .
The easier it is to understand the code, the lesser will be the number of bugs. Even if they are bugs, they can be found easily.
In short, while writing a code, don’t be a lawyer, be a programmer.
9) Avoid unnecessary refactoring.
While reading code written by others, programmers are often tempted to try and fix what may seem “different” from their programming style.
This type of refactoring can be dangerous because trying to change working code is again a possibility of introducing new bugs
10) Fix bugs – don’t introduce more.
Fixing bugs is always a battle between resolving the earlier ones v/s introducing new ones. Extra care has to be taken while fixing bugs as not to introduce new ones perhaps even more critical than the older ones. Try to fix the bug with minimal change to the code as possible.
11) Test frequently.
Testing frequently will allow finding problems early.
This will save development time for 2 reasons –
a) Late bug fix may take longer to fix and test. The smaller bug might grow into bigger one as development advances
b) If the bug is found while the final release is due it will delay the release.
12) Test before starting to work with old version.
One common scenario is when you need to start work on old or recent version. You take the version into your computer and start adding new featuring and you encounter an error. You debug it for long only to find that the problem was in base code. Hence it is always a better idea to do small testing before starting coding on old version.
13) Write test before fixing a bug.
When you uncover a problem in your code, write a test case that exposes this problem before fixing the code. This way if the problem appears it will be caught with the test.
14) Debug the problem.
Often when you have written a bad code, you have a much better idea of what the good code should look like. Remember that just because you have written it does not mean you should keep it. While debugging the problem first convert bad into good code and then carry on with debugging. This will make debugging the code even easier.
15) Minimize potential problems by avoiding copy paste syndrome.
If a part of code having a bug is copy pasted at many locations then same problem of debugging will be repeated at many places. Hence before using a part of code at other location , debug that part of code properly to ensure its bug free before using.
16) Fixing the symptom and not the problem.
Ask yourself how many times you have fixed the same type of bug. It only indicates that the symptom is being fixed and not the root cause of the problem. This will lead to bugs coming up at different locations in different forms and hence increase debugging time.
Referred link :
code.rkevin.com
blog.interviewstreet.com
msdn.microsoft.com