Have you checked whether your program works better with that fix?JensBNielsen wrote:I actually discovered the >> error by reading my own post here. It should be >= instead.
The compiler prints a warning about an uninitialized variable, and I check each warning (and if it is my program, I fix the code in order to remove all warnings).JensBNielsen wrote:Thanks for discovering the difference in w_check_direction and b_check_direction. How did you discover that?!
If you have no problem to understand your own code, and if you therefore are able to identify bugs in the code which you detect by testing, then you may of course postpone making your code "clean and straight".JensBNielsen wrote:First I would just like the hashtables to work properly.
Then I would like my code to be clean and straight, but I would also like to add new knowledge and ideas - and I have a lot!
If, however, you see that your program does not work properly with respect to your hashtable implementation, and you do not understand all of that hashtable code well enough, then I strongly recommend - as most others here would probably do - to start _carefully_ with cleaning. You won't be able to fix any bug in complex code if you don't understand your code fully, which means that by changing two lines you'll most probably introduce two new bugs.
Of course cleaning is only a first step, and not the most important one, but I think it has to come first. You are tempted of course to say "Come on, I'm just one or two tiny bugs away from heaven, so why bother with cleaning now, I can do that later?!". Nice if you - or someone else here - find these tiny bugs quickly. But if you don't? You will try 20, 50, 100 different fixes at various places until you give up, having improved your Elo by some -50 points.
O.k., I exaggerated, but not too much.
After cleaning, now that you have managed to have code that is easier to change, the second step IMO is then to improve testability of the code. This is much work and may include things like:
- making the code "safe" by adding assert's;
- isolating functionality, i.e. making different pieces of code more independent from each other, in order to be able to test one functionality isolated from the other;
- writing specific debugging and testing code and managing to trigger specific tests from the user interface.
It is fun to reach a state where you can see that you really have your program under control - and not vice versa!
Just my 2 cents, again ...
Sven