hiatus good for bug-finding

[smcracraft]

Are you talking about GNU Chess 5, or is this a new program?

IIRC, Stuart never worked on version 5, which was a completely new program in bit boards. Just the early versions.

By the way, if you have some good tests I can automate the program's testing with, I'll be delighted.

[Don]

Another good way to find bugs is to try to explain your code to others. Quite often you'll go "so this happens this way and then... oh... wait...", finding a bug without the other person even saying anything.

This is one of the things that make code reviews useful in a programming job. Usually the reviewer is unfamiliar with the code, and you have to explain to them exactly what the code *actually* does. So you systematically work through all the possibilities, and it will usually be obvious if there is some edge case where the code doesn't do what you intended.

Having someone else do a code review is a good practice - but the person must be diligent of course and not just skim.

When you don't give anyone else access to your code, you have to use other methods.

Testing is an important consideration, and I don't mean just running games but very specific tests of functional units. I do that mainly when I'm writing new code.

One method I use a LOT is to write 2 versions of any new routines that I create. For instance when testing incremental zobrist hashing, I have a routine that computed the hash from scratch - and then a debug version of my program compared between them. PERFT helps make sure your move generator is correct, but I have special generators (such as out of check generators) that I can compare against the standard generator that has already been verified with perft. (Or I can test them with perft.)

In general, you can build a dumb simple version of most routines that are easy to debug and get right and compare them against the high performance version of the same routine. Even if they are not that easy to get right having 2 different routines to compare against each other is useful - as long as they are written in significantly different styles.

I also try to use assertions as much as possible. It takes some discipline to do this, but it saves a lot of time when one actually triggers - because it usually happens right after some change and alerts you right away that something is wrong.

So as another general rule you want to catch new bugs as quickly as possible because when something does show up you want to have high confidence that it was recently introduced. If you have many bugs that have existed for many months, your job is much more difficult.

Perhaps my best bug detecting tool is Larry Kaufman. I'm doing all technical stuff to find bugs but Larry can often beat me to punch just by using observation.