Re: To Initialise or not

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Patrick Richard Wibbeler wrote:
> 
> What if either of the following occur...
> 1] For some reason the language is changed so that pointers are no longer
> initialized to null

Then I will personally find the instigators of this change, and SHOOT THEM.

At least using Ada 95 as a model for how Ada will evolve, I would say that
this is a risk that can reasonably be discounted. Furthermore, it is a risk
that can be applied equally well to every other language feature. For example,
what if the ability to use "others" in aggregates is removed?

I wouldn't use the evolution of C as a guide to the evolution of Ada.

> 2]  Someone attempts to re-write the code in another language that
> doesn't initialize pointers to null.  He/she may not know whether or not
> to initialize the pointer to null without looking closely at the code..

Not true. If someone is doing a mechanical translation of Ada to language X
(or X++?), then they should know that all pointers must have an initial value,
and that, unless explictly stated, the initial value is null. They should also
know that all attempts to dereference that object should be preceded by a check
to see if the object is null (otherwise, they aren't preserving the Ada semantics).

You could argue that the mechanical translation can be optimized, and that's true,
but you can do that optimization without the explicit initialization. In fact,
explicit initialization may make it harder to do the analysis, depending upon what
kind of flow analysis tools are being used.

You could also argue that the maintainer has a poor knowledge of Ada (or
X), and that explicit initializations make it less necessary to know the rules
of Ada, but that's going to get you into trouble that no amount of explicit
initialization will help!

Of course, it gets interesting if the target language has no concept of null
(or for that matter, of access types!). However, explicitly setting pointers
to null won't help that, either.

> Readability is not just for now.  It is for later.

Exactly. This is why anything added for readability should be _obvious_ to the
future maintainer, since the author isn't necessarily going to be around to
explain his coding style. I'm not seeing how this approach is quite so obvious
(particularly given the divergent explanations from its practitioners as to what
it's supposed to mean!).

> The main point is who knows who or why the code will be used in the
> future.  At such a small cost, the readability/maintainability in the
> future could be large.

Adding lots of little things at a small cost, without justifying them,
can often add up to something large in the future -- a large negative
maintenance cost.

-- 
LMTAS - "Our Brand Means Quality"