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.1 required=5.0 tests=BAYES_00,INVALID_MSGID, TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6bd5598e439c30ef,start X-Google-Attributes: gid103376,public From: "W. Wesley Groleau (Wes)" Subject: Re: explicit null Date: 1996/05/09 Message-ID: <9605091727.AA01200@most>#1/1 X-Deja-AN: 153917535 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU processor" at may 9, 96 8: 12 am mailer: Elm [revision: 70.85] newsgroups: comp.lang.ada Date: 1996-05-09T00:00:00+00:00 List-Id: :> Subject: Re: To Initialise or not :> So, here's my summary [of his opinions on explicitly initializing to null]: With what will REALLY happen, IMHO. :> 1. The convention is not self-evident. It has to be explained somewhere. If the :> maintainer fails to get that understanding, it will cause confusion while (s)he :> searches for the meaning to this "useless" code. The chances of the above search occurring under deadline pressure are 'null' :-) With no pressure, about 5%. If what I've observed in twenty years of working with other people is typical, more than half will not notice the explicit null. Of those that do notice it, most will think, "Whoever wrote this doesn't know Ada very well." They will remove the "unnecessary construction" and maybe even search the file for other "unnecessary constructions." Having the mindset to find such, they will fmisjudge things that ARE necessary and remove them too. (Yes, I've done it myself, and I'm not alone.) Then, if they are fortunate to work where there are peer reviews, they will go to a review where everyone will say, "I didn't find anything wrong with it." (And the honest ones will add, "Of course, I only looked at it for five minutes.") :> 2. Even if the convention is understood, its value is hampered by the fact that :> it doesn't convey information at the point where it is needed (the algorithm :> using the data structure). :> :> 3. As a corollary to #2, further maintenance of the code makes it easy for the :> coding convention to be inconsistently applied. This further obfuscates the :> code. This effect magnified by the one I've already described. :> 4. Because it is "active" code which the compiler analyzes (unlike a comment), :> there is also the danger (admittedly slight) of a coding error being :> introduced. This effect magnified by the one I've already described. :> Overall, I stand by my original statement: I don't see the attraction of this :> style. Me, neither. One exception: I have run across a compiler that failed to initialize access fields in certain nested record situations. But then I would take half a line AT EACH SUCH LOCATION to explain why there's an explicit null. -- --------------------------------------------------------------------------- W. Wesley Groleau (Wes) Office: 219-429-4923 Magnavox - Mail Stop 10-40 Home: 219-471-7206 Fort Wayne, IN 46808 elm (Unix): wwgrol@pseserv3.fw.hac.com ---------------------------------------------------------------------------