Code inspection or buying spectacles ?

[Henk]

No. Unit tests.

Just found this bug today in king shield computation. Must have been there for months:

Code: Select all

var result = (nShieldPawnsRow2 * 5 *  + nShieldPawnsRow3 * 2) * ChessPiece.CENTI_PAWN;

Strange that it returned 0 when nShieldPawnsRow3 is 0 (not)

[Sven]

Strange that it returned 0 when nShieldPawnsRow3 is 0 (not)

You expected it to return a little bit more than 0 since you multiplied by "+0", didn't you?

[Henk]

Strange that it returned 0 when nShieldPawnsRow3 is 0 (not)

You expected it to return a little bit more than 0 since you multiplied by "+0", didn't you?

Yes say 15 * ChessPiece.CENTI_PAWN in initial position. That explains these strange g7-g6 moves while leaving bishop on f8. Or early c7-c6 moves.

Maybe 15 is still too small.

[Henk]

Strange that it returned 0 when nShieldPawnsRow3 is 0 (not)

You expected it to return a little bit more than 0 since you multiplied by "+0", didn't you?

Yes say 15 * ChessPiece.CENTI_PAWN in initial position. That explains these strange g7-g6 moves while leaving bishop on f8. Or early c7-c6 moves.

Maybe 15 is still too small.

But it's counting weak pawns too. So there is overlap.

[Ras]

No. Unit tests.

In practice, you don't do unit tests anyway. Mostly. Or only on trivial helper functions. The amount of unit test code easily tops production code, and that is simply not feasible for a one man chess project.

In bigger projects, a major side effect is that people don't even do refactoring when necessary because that would also involve changing all the unit tests (the point of refactoring being that the definitions of "units" change). So over time, you get a somewhat reliable, but unmaintainable mess.

Unit tests are nice in theory, but rarely applied in practice. Just like flossing.

[matthewlai]

No. Unit tests.

In practice, you don't do unit tests anyway. Mostly. Or only on trivial helper functions. The amount of unit test code easily tops production code, and that is simply not feasible for a one man chess project.

In bigger projects, a major side effect is that people don't even do refactoring when necessary because that would also involve changing all the unit tests (the point of refactoring being that the definitions of "units" change). So over time, you get a somewhat reliable, but unmaintainable mess.

Unit tests are nice in theory, but rarely applied in practice. Just like flossing.

The current project I am working on (that also happens to be a board game engine) has a nice and large suite of unit tests covering almost everything independently testable. It doesn't add significantly to developer workload, and have detected countless bugs that we probably would not have never caught otherwise.

Like most tools in programming - it's useful if you know how to use it, it's not useful if you don't.

[Ras]

Like most tools in programming - it's useful if you know how to use it, it's not useful if you don't.

However, let's not forget - like many programming problems, things are way easier when there's a company behind it that is able and willing to throw a (nearly) infinite amount of manpower and money at it to get the best result possible because it is also a prestige project. And if that project does not even have to be directly profitable.

Plus that most chess engines are, comparably, toy projects. At most, they are concerned with multithreading, and I'm not even that, with a Cortex-M4. Alpha-Go has so many servers behind it that the power bill alone would be likely to cause headache to hobbyists, and of course you need different strategies for such a project.

It's just that most leisure projects aren't in that state because there is only so much time you have on top of a paying job and possibly family, and I would value proper documentation over unit tests at any time for projects of that relatively small scale.