Often in coding, I find it very slow and difficult to detect the root cause of a bug and sometimes I end up going to wrong point in my code. It's painful. I know that to detect the root cause of a bug is a very important skill for programmers. Does anybody have a trick or technique to suggest a good way of finding the root cause?
closed as too broad by MichaelT, BЈовић, Kilian Foth, World Engineer♦ Jul 29 '13 at 13:42
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
Ask why a lot, and keep asking it until the problem is clear.
This technique is often referred to as "5 Whys". You can read more about "5 Whys" on wikipedia.
You might also be interested in reading answers to the question What is your most useful technique for finding (or preventing) bugs?
Yeah nice question though may sound very abstract or poorly directed. However if it is directed or not, again depends your perspective.
Yess debugging is very very important skill. The best/perfect way to deal with them is to have holistic view to them, strategizing for them - along their life cycle.
I dont want to be theoretical here. To start with we can start with their source.
Bugs are introduces by us - developers, due to
Apart from understanding of tech other development habits like following coding/development standards, conventions (to which others adhere to and expect things to be in a specific way), proper design patterns will ease the development efforts -> leading to cleaner codebase -> less confusion -> thus effectively resulting/introducing in less bugs.
The next important thing is mastering debugging tools. Many developers do not take dedicated efforts to learn debugging tools. Every technology today have very sophisticated debugging tools. If you master one you can easily replicate the same skills in other technology. For example I first learnt Visual Studio features like Autos, Locals, Breakpoints, Conditional breakpoints, Watches, Thread Window etc. These feature concepts follow similar names in other IDEs. So I was able to very quickly use same stuff in Eclipse. The same follows in web debuggers like Chrome developer tools, Firebug. However there are many technology related stuff too like Profilers and element inspectors in web debuggers. Also Visual Studio 2012-2013 brings many new features that really need very dedicated efforts to completely understand them and practice them.
So thats my second point:
If you know technology well, you know what you want to accomplish (business scenario/ domain knowledge) and if you know how to track things when they misbehave, you are a king.
Also there is no doubt there are these obvious factors - experience and practice. But more conscious you are while learning and developing more quicker you will be in tracking things.
As a personal experience - when I was working a lot on JSP, Expression Language and related stuff I was able to tell them what might be going wrong just by listening to their problem behavior. So soon you start recognizing things quickly.
And whenever I stuck in some weirdly behaving code, I put breakpoint before it, hit debug, when breakpoint is hit check if all locals and globals have desired value and then step through each line looking for any changes that happens to those locals and globals.
Finally we have google: attach "best practices" to technology name, hit search and keep reading like this.
A trick or something? Well sort of - breakpoints and step throughs always helped me. Sometimes when I dont understand whats going wrong I take snapshot of suspicious behavior I find (but dont understand completely) while stepping through and put that snapshot with explaination on stackoverflow. :) Or else you can use tools like JSFiddle to explain problem in action. After all what you want is to get things fixed quickly and properly. ;p
These links may help you
Testing a huge project at once will give you a headache. The best way to detect root cause of problem is to test the smallest units individually. When all the smallest units are correct then test bigger units made by 2 of them and so on till you get to the top.
Make a habit of maintaining test cases for all units so that if a new bug appears after you change some part then you don't have to write the whole thing again. You can apply the tests to see what is the problem and exactly where.
Maintaining individual modules separately with their test cases can be save you a lot of problems in the long runs. When you want to make changes make changes in the smallest units, test them and then use them.
That can help you in the long run. Believe me, I didn't have the habit of maintaining testing code alongwith the code and it made my life hell. I am trying to fix it. Don't make the same mistake.