[Freeciv-Dev] Re: (PR#2370) Path finding

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sat, Feb 22, 2003 at 08:44:11AM -0500, Ross Wetmore wrote:
> 
> Raimar Falke wrote:
> >On Wed, Feb 19, 2003 at 04:40:35PM +0000, Per I. Mathisen wrote:
> >>On Wed, 19 Feb 2003, Raimar Falke wrote:
> [...]
> >>Maybe the warmap code itself wasn't easily maintained, but code which
> >>_uses_ the warmap can be written in an easily maintained manner. Code
> >>which uses pf directly is going to be very ugly, and rather
> >>unmaintainable, simply because the pf API is so big.
> >
> >>Correctness be damned, Raimar. 
> [...]
> >Maintainability is important in the long run. No doubt about this. But
> >correctness is still more important.
> [...]
> >     Raimar
> 
> Correctness is too often a codeword for religious preferences,
> i.e. (ab)used subjectively vs objectively.
> 
> Robustness is a better word as that actually means something
> useful to the practical code excution during game play.

The dictionary says:
  1) Free from error or fault; true or accurate.
  2) Conforming to standards; proper: correct behavior.

I mean 1) here. I want that the code works as defined in the range of
defined input values. For most of the code there is not even a
semi-formal definition of what is the expected behavior. Same is true
for the input range. This causes a blurring and so "defined input
values" has to be replaced by "expected input values" or "common input
values".

Robustness is another issue and is about handling input values which
are outside the defined/expected/common input range. There is no
problem with adding extra handling if there are clear semantics what
can be done in such a case and a clear idea what the user may
expect. If this isn't the case I'm for assert/die/LOG_ERROR so that we
have a cleaner picture when and why such code paths are used.

> Maintainability is *always* superceded by speed when performance is
> an issue

With this warmap won't be killed at all. warmap is the biggest cpu
eater so "performance is an issue".

> , and there is never a rationale for doing something inefficiently
> when an equally maintainable efficient choice is available.

I agree.

> The trick is always to avoid premature optimization
> and thus starting off with maintainablity in front is certainly
> a reasonable first pass. It is however, not a hard ordering.
> 
> Maintainability is also too often abused for religious goals, and
> coupled with inflexible ordering becomes just another religion
> enforcement tool by those that place it high on their priority
> list.

> A kitchen sink blob of every possible option may be wonderfully
> maintainable to some since everything is laid out in all detail, and
> totally inscrutable to others. On the otherhand a structured
> hierarchical breakdown may be very maintainable to some, and totally
> inscrutable to those that are incapable of wrapping their heads
> around the organizational separation of elements in the hierarchy.

I think the hierarchical will always win for medium to big sized code
bases.

> Generally though, the monolithic blob is losing out to the
> hierarchical programming models evolving as base concepts and
> extensions.

> The Golden Rule here is always be a little bit flexible ...

Nothing is set in stone.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Only one human captain has ever survived battle with the Minbari
  fleet. He is behind me. You are in front of me. If you value your 
  lives, be somewhere else."
    -- Ambassador Delenn, "Severed Dreams," Babylon 5