What helps to you improve your ability to find a bug?

Question

Hi, I want to know if there are method to quickly find bugs in the program.

It seems that the more you master the architecture of your software, the more quickly you can locate the bugs.

How the programmers improve their ability to find a bug?

Answer 1

Logging, and unit tests. The more information you have about what happened, the easier it is to reproduce it. The more modular you can make your code, the easier it is to check that it really is misbehaving where you think it is, and then check that your fix solves the problem.

Answer 2

Stepping through the code, examining flow/state where unexpected behavior is occurring. (Then develop a test for it, of course).

Answer 3

I will assume you mean logic bugs. The best way I have found to capture logic bugs is to implement some sort of testing scheme. Check out jUnit as the standard. Pretty much you define a set of accepted outputs of your methods. Every time you compile your system it checks all of your test cases. If you have introduced new logic that breaks your tests, you will know about it instantly and know exactly what you have to fix.

Test driven design is a pretty big movement in programming right now. You will be hard pressed to find a language that doesn't support some kind of testing. Even JavaScript has a multitude of test suites.

Answer 4

I personally take the approach of thinking about where the bug may be in the code before actually opening up the code and taking a look. When you first start with this approach, it may not actually work very well, especially if you are pretty unfamiliar with the code base. However, over time someone will be able to tell you the behavior they are experiencing and you'll have a good idea where the problem is located or you may even know what to fix in the code to remedy the problem before even looking at the code.

I was on a project for several years that maintained by a vendor. They were not very good debuggers and most of the time it was up to us to point them to an area of the code that had the problem. What made our problem worse was that we didn't have a nice way to view the source code, so a lot of our "debugging" was just feeling.

Answer 5

Writing Debug.Write(message) in your code and using DebugView is another option. And then run your application find out what is going on.

Answer 6

Error checking and reporting. The #1 newbie coder debugging mistake is to turn off error reporting, avoid checking for whether what's going on makes sense, etc etc. In general, people feel like if they can't see anything going wrong then nothing is going wrong. Which of course could not be further from the case.

Instead, your code should be chock full of error conditions that will make lots of noise, with detailed reporting, someplace you will see it. (This doesn't mean inside a production web page.) Then, instead of having to trace an error all over the place because it got passed through sixteen layers of execution before it finally got someplace that broke, your errors start happening proximately to the actual issue.

Answer 7

Here's a prophylactic method after you have found a bug: I find it really helpful to take a minute and think about the bug.

1. What was the bug exactly in essence.
2. Why did it occur.
3. Could you have found it earlier, easier.
4. Anything else you learned from the bug.

I find taking a minute to think about these things will make it far less likely that you will produce the same bug in the future.

Answer 8

Divide and conquer. Whenever you are debugging, you should be thinking about cutting down the possible locations of the problem. Every time you run the app, you should be trying to eliminate a possible source and zero in on the actual location. This can be done with logging, with a debugger, assertions, etc.

Answer 9

"Architecture" in software means something like:

• Several components
• The components interact across clearly-defined interfaces
• Each component has a well-defined responsibility
• The responsibility of one component is unlike the responsibilities of other components

So, as you said, the better the architecture the easier it is to find bugs.

First: knowing the bug, you can decide which functionality is broken, and therefore know which component implements that functionality. For example, if the bug is that something isn't being logged properly, therefore this bug should be in one of 3 places:

1. In the component that's responsible for logging (your logging library)
2. Or, above that in the application code which is using this library
3. Or, below that in the system code which this library is using

Second: examine the data transfered across the interfaces between components. To continue the previous example above:

• Set a debugger breakpoint on the application code which invokes the logger API, to verify whether the logger API is being used correctly (e.g. whether it's being invoked at all, whether parameters are as-expected, etc.).
• Doing this tells you whether the bug is in the component above this interface, or in the component that's below this interface.
• Repeat (perhaps using binary search if the call stack is very deep) until you've found which component is at fault.

Answer 10

It seems that the more you master the architecture of your software ,the more quickly you can locate the bugs.

After understanding the architecture, one's ability to find bugs in the application increases with their ability to identify and write extensive tests.

Answer 11

Know your tools.

Make sure that you know how to use conditional breakpoints and watches in your debugger.

Use static analysis tools as well - they can point out the more obvious issues.

Answer 12

Experience makes you a better debugger. Pay close attention to the bugs that you AND others commonly make. Try to figure out if/how these bugs apply to ALL code that affects you, not the single instance of where the bug was seen.

Raymond Chen is famous for his powers of psychic debugging.

Most of what looks like psychic debugging is really just knowing what people tend to get wrong.

That means that you don't necessarily have to be intimately familiar with the architecture / system. You just need enough knowledge to understand the types of bugs that apply and are easy to make.

Answer 13

• Use programming methods that produce fewer bugs in the first place.

If to implement a single stand-alone functional requirement it takes N separate point-edits to source code, the number of bugs put into the code is roughly proportional to N, so find programming methods that minimize N. Ways to do this: DRY (don't repeat yourself), code generation, and DSL (domain-specific-language).

• Where bugs are likely, have unit tests.

Obviously.
IMHO, the best unit tests are monte-carlo.

• Make intermediate results visible.

For example, compilers have intermediate representations, in the form of 4-tuples. If there is a bug, the intermediate code can be examined. That tells if the bug is in the first or second half of the compiler.

P.S. Most programmers are not aware that they have a choice of how much data structure to use. The less data structure you use, the less are the chances for bugs (and performance issues) caused by it.

Answer 14

I find tracepoints to be an invaluable debugging tool. They are a bit like logging, except you create them during a debugging session to solve a particular issue, like breakpoints.

Printing the stacktrace in a tracepoint can be especially useful. For example, you can print the hash code and stacktrace in the constructor of an object, and then later on when the object is used again you can search for its hashcode to see which client code created it. Same for seeing who disposed it or called a certain method etc.

They are also great for debugging issues related to window focus changes etc, where the debugger would interfere if you drop in break mode.

Answer 15

Static code tools like FindBugs

Answer 16

When you come to the point that you think there must be a bug in the OS, check your assertions -- and put them into the code with "assert" statements.

Conversely, as you are writing the code, think of the range of valid inputs for your algorithms and put in assertions to make sure you have what you think you have. Same goes for output: Check that you produced what you think you produced.

E.g. if you expect a non-empty list:

l = getList(input)
assert l, "List was empty for input: %s" % str(input)

Answer 17

Assertions, assertions, and assertions.

Some areas of our code has 4 or 5 assertions for each line of real code. When we get a bug report the first thing that happens is that the customer data is processed in our debug build 99 times out a hundred an assert will fire near the cause of the bug.

Additionally our debug build perform redundant calculations to ensure that an optimized algorithm is returning the correct result, and also debug functions are used to examine the sanity of data structures.

The hardest thing new developers have to contend with is getting their code to survive the assertions of the code gthey are calling.

Additionally we do not allow any code to be putback to toplevel that causes any integration or unit test to fail.

Answer 18

Sleep and rest.

Answer 19

I'm part of the QA team @ work, and knowing anything about the product and how it is developed, helps a lot in finding bugs, also when I make new QA tools I pass it to our dev team to test it, finding bugs in your own code is just plain hard!

Some people say programmers are tainted, so we cannot see bugs in their own product; we are not talking about code here, we are beyond that, usability and functionality itself.

Meanwhile unit testing seams to be a nice solution to find bugs in your own code, its totally pointless if you're wrong even before writing the unit test, how are you going to find the bugs then? you don't!, let your co-worker find them, hire a QA guy.