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: bobduff@world.std.com (Robert A Duff) Subject: Re: To Initialise or not Date: 1996/04/30 Message-ID: #1/1 X-Deja-AN: 152290485 references: <318508FE.204B@sanders.lockheed.com> <3184E9CE.5C7A@lmtas.lmco.com> <3185E379.7C20@lmtas.lmco.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-04-30T00:00:00+00:00 List-Id: In article <3185E379.7C20@lmtas.lmco.com>, Ken Garlington 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