Re: To Initialise or not

[bobduff@world.std.com (Robert A Duff)]

In article <3185E379.7C20@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>OK, so if an initialization to null lets me know that I may see the
>object compared to null later:

No, sorry, I just meant the "if ... = null" as an *example*.  The
general point is: If I explicitly initialize, then I plan to read that
value, at least in some cases.  If I don't, then I promise I won't read
that value.

>3. How do you relay this convention to the reader, so that they understand
>   what it means?

The coding convention is easy to understand.  Do you know when it's
necessary to explicitly initialize an Integer variable?  The coding
convention is to explicitly initialize pointer variables in exactly the
same cases -- namely, when the code plans to read that value, before
some other assingment statment.

In other words, pretend that you're coding in a language that's just
like Ada, except that there's no default initial value for pointers.
Write the code accordingly.  Since this mythical language is a subset of
Ada, this is safe.

>It just seems like effort without much payoff, at least from a maintainability
>standpoint...

Well, I admit, it's not that big a deal.  It's little effort, with
little payoff, so we could argue endlessly about the payoff.

>> ":= 0" might be mistaken for ":= O", for an integer, if there's
>> an integer variable O lying around.  Or ":= mull" might have meant ":=
>> nell", for a private type, if there are "mull"s and "nell"s lying
>> around.  This doesn't seem like a big risk to me.
>
>And I would equally object to someone initializing all integers to zero,
>just to show it's an integer, or to say that they _might_ be comparing the
>integer to zero later! 

I agree.  You don't initialize integers to show they're integers, and you
don't initialize them because of some specific comparison with zero.
You initialize them if and only if the initial value can be read.
I'm just advocating doing the same thing for pointers.

>...In my mind, if it's necessary to initialize
>the value, do so. If no initial value is needed (or the language gives
>you the correct initial value automatically), why take the risk, even if
>it's not a big one? Are you some sort of thrill-seeker? :)
>
>What about other default initializations, like others => ... ? It might
>not be less efficient (code-wise) to always spell out every component,
>and then you wouldn't be relying on the "efficiency hack" of this clause,
>and trusting the compiler to do the initialization of all unspecified
>components. Is this also part of such a coding style?

Other default initializations are different, since they are under the
control of the programmer, so you can define a "reasonable" default
initial value when appropriate, and you can write a comment allowing
clients to rely on it.  But initializing all access values to null does
*not* constitute a "reasonable" initial value, in many cases.

- Bob