Problem with bitboard knight attack generator

[hgm]

One must be careful to avoid the unhealthy desire for short term gains which result in high long term costs. Compared to a slower but more sure approach, a rushed project will always cost more and produce results of lower quality.

Nonsense. Checking for conditions that will and can never occur is a pure waste of time. The total benefit integrated over eternity will be exactly zero.

[Sven]

One must be careful to avoid the unhealthy desire for short term gains which result in high long term costs. Compared to a slower but more sure approach, a rushed project will always cost more and produce results of lower quality.

Nonsense. Checking for conditions that will and can never occur is a pure waste of time. The total benefit integrated over eternity will be exactly zero.

Have you ever been involved in real commercial software development projects?

And how can you know which conditions "will and can never occur"?

Sven

[Dave_N]

I actually think the only problem with the setFen issue was the question of where is the best place to error check the fen ?

if you assume a function has a working input and output then you don't call the function until you have called IsFenValid() for example.

[Sven]

I say "never crash on external input".

This is the only good way of doing things. Long, long ago in school I learned the technique as "defensive programming", but by any name it's the best practice.

I think it depends on the project, if you have X amount of time until alpha (example: your software needs to have a working demo and you can use a laptop / video to show your investors) then why waste time fixing some error checking that is perfectly straightforward when you don't need a playable demo until beta testing, and even then you can wait for someone to complain about the bug because the official release doesn't happen until after a month of waiting for bug reports.

My answer ... the code can be neater if full error checking is done in the first place and sometimes things have to be rewritten.

From my experience it is simply the wrong view to say that "fixing some error checking is a waste of time". It is always cheaper to include error checking immediately when designing the algorithm. If you add it later then you add much more testing effort, and there is a high risk that you introduce new errors by changing the algorithm (or its implementation) to include error checking. Better include it right from the beginning.

Part of that "error checking" topic can also be to include ASSERT's, which can sometimes help to reduce the amount of error checking code of the release version drastically. (But ASSERT's are not always the right solution, e.g. not always applicable for external input.)

To a certain degree this does also apply to chess programs, where an FEN parser is only one (perhaps less important) example.

Underestimating the need for error checking and/or ASSERT's is one of the best ways to unreliable code.

Sven

[Sven]

Ok so I am almost finished with the PGN parse error checking, is there anything wrong with this pattern matching code for the move strings format.

What about opening a new thread for this one?

Sven

[Dave_N]

Changed my mind about posting the code

[Dave_N]

I say "never crash on external input".

This is the only good way of doing things. Long, long ago in school I learned the technique as "defensive programming", but by any name it's the best practice.

I think it depends on the project, if you have X amount of time until alpha (example: your software needs to have a working demo and you can use a laptop / video to show your investors) then why waste time fixing some error checking that is perfectly straightforward when you don't need a playable demo until beta testing, and even then you can wait for someone to complain about the bug because the official release doesn't happen until after a month of waiting for bug reports.

My answer ... the code can be neater if full error checking is done in the first place and sometimes things have to be rewritten.

From my experience it is simply the wrong view to say that "fixing some error checking is a waste of time". It is always cheaper to include error checking immediately when designing the algorithm. If you add it later then you add much more testing effort, and there is a high risk that you introduce new errors by changing the algorithm (or its implementation) to include error checking. Better include it right from the beginning.

Part of that "error checking" topic can also be to include ASSERT's, which can sometimes help to reduce the amount of error checking code of the release version drastically. (But ASSERT's are not always the right solution, e.g. not always applicable for external input.)

To a certain degree this does also apply to chess programs, where an FEN parser is only one (perhaps less important) example.

Underestimating the need for error checking and/or ASSERT's is one of the best ways to unreliable code.

Sven

Probably the best practice, although in any app there are likely to be non-error checked assignments and variable usage. If for example you have a class called Foo ...

Code: Select all

class Foo
{
public:
   Foo()
{
    mem = new SmallBlockOfMemory(this); // new fails because the //system is out of memory
}
~Foo()
{
if( mem )
{
    delete mem;
   mem = NULL;
}
}

SmallBlockOfMemory *mem; // with own constructor
};

and "new" isn't overridden until much later when Foo has become a major project.[/code]

[Sven]

I actually think the only problem with the setFen issue was the question of where is the best place to error check the fen ?

if you assume a function has a working input and output then you don't call the function until you have called IsFenValid() for example.

But IsFenValid() needs to parse the FEN in order to validate it, so you parse it twice if it is valid. Usually parsing and error checking should be combined. Look how compilers work. They don't have two separate functions "IsProgramValid()" and "ProduceObjectCodeFromProgram()".

Separating validity check and actual processing is best done if the validity check can be performed by looking at certain properties of the data to be processed, like for instance the size, or the range of some parameters. But if you need to look at the whole thing itself to decide whether it is valid then you are in fact doing almost the same work for validation and actual processing, so it should be done in one step.

There may be exceptions of course, e.g. if a separate validation is an external requirement.

Sven

[ZirconiumX]

David,

stop.

Matthew:out

[Dave_N]

but even though compilers have code-completion and intelli-sense they don't compile and link while the file is being edited. Although mistakes will be shown with red underlines.