From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c1131ea1fcd630a
X-Google-Attributes: gid103376,public
From: Ken Garlington <garlingtonke@lmtas.lmco.com>
Subject: Re: To Initialise or not
Date: 1996/04/30
Message-ID: <3185E379.7C20@lmtas.lmco.com>#1/1
X-Deja-AN: 152243179
references: <318508FE.204B@sanders.lockheed.com>
 <3184E9CE.5C7A@lmtas.lmco.com> <DqnGoz.10v@world.std.com>
content-type: text/plain; charset=us-ascii
organization: Lockheed Martin Tactical Aircraft Systems
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 2.01 (Macintosh; I; 68K)
Date: 1996-04-30T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert A Duff wrote:
> 
> To me, "X: Some_Pointer;" means X is a pointer, which I plan to
> initialize at some later point before reading it, whereas, "X:
> Some_Pointer := null;" means X is is a pointer, where the first use
> might well be "if X = null then ...".

OK, so if an initialization to null lets me know that I may see the
object compared to null later:

1. What do I do with this information? Why is it useful for me to know
   that you may later be comparing the value to null?

2. What should I conclude if this convention is broken -- for example,
   if you compare it to null, but don't explicitly initialize it to null,
   or conversely initialize it to null but fail to compare it to null?
   Should I be concerned? Is it just a case where a null compare was
   removed during maintenance, and I shouldn't care? Or what?

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

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

> ":= 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! 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?

-- 
LMTAS - "Our Brand Means Quality"