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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7dd9b82cd363f55b X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Coding Standards Date: 1996/05/20 Message-ID: <4nppd5$61@goanna.cs.rmit.EDU.AU> X-Deja-AN: 155736694 references: <9605151401.AA04364@most> <319B286E.3B2E@lmtas.lmco.com> <4nh3n7$55g@goanna.cs.rmit.EDU.AU> <319C52B2.36F6@lmtas.lmco.com> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-05-20T00:00:00+00:00 List-Id: I wrote: I understand why Ada initialises pointers to null, and I wouldn't want that changed, but if I want to check that a variable is properly initialised, I want to _see_ an initialisation. Ken Garlington writes: >Is this because you don't trust the compiler to obey the language rules in >this area, or some other reason? It's because I want to _see_ the initialisation. It's not the _compiler_ I don't trust (although, as it happens, I don't trust my compiler; it's GNAT, and from time to time our technical support people do something that makes 'gcc -c foo.adb' completely stop working; software _as shipped_ != software _as installed_). It's _me_ I don't trust. I am a bear of very little brain. I have worked with _lots_ of languages, and continue to use several. The policy I described (initialise constants in declarations, initialise variables as close as reasonable to first use) is one that - makes sense in _every_ language I use - makes sense _whatever_ the data type of a variable is. If we take "abstract data types" and "uniform reference" at all seriously, and in Ada I thought we were supposed to, I _should_ be using a convention for initialisation which doesn't force me to rewrite the code if I switch from array indices to pointers or vice versa. Somebody reading my code (probably me) shouldn't have to look up the type declaration (which may be in some other package entirely) to find out that what _looks_ like an uninitialised variable is actually ok. >Furthermore, what about cases like: >(1) type Some_Thingy_Type is record > Some_Component : Integer := 0; > end record; > Foo : Some_Thingy_Type; -- or should I explicitly initialize it? The rule I use is type independent. It's not the ":= 0" in the type declaration I mind; it's that I don't like relying on it, not because the compiler will get it wrong, but because I will. I actually prefer type Some_Thingy_Type is record Some_Component: Integer; end record; Default_Thingy_Type: constant Some_Thingy_Type := (Some_Component => 0); Foo: Some_Thingy_Type; begin ... Foo := Default_Thingy_Type; If there is a "normal" initial value for a type, I WANT A NAME FOR THAT VALUE! >(2) type Name_Type is String(1 .. 10); > Blank_Name : constant Name_Type := (others => ' '); > -- is "others" too implicit? No, of course not. My rule was about initialising variables. I said nothing about "implicit". >> For teaching purposes, at any rate, I am >> *for* any tool that will help to detect uninitialised variable use >> *against* any "solution" to the problem that requires programmer >> intervention; if the students were savvy enough to use such a >> solution, they wouldn't need it so much. >This is certainly useful; do you see your coding standard as a "tool" in this >context, or are you saying that you would like analysis tools and language >features (e.g. Normalize_Scalars, 'Valid) as "tools"? 'Valid is exactly the kind of thing I am _against_ in this context because it requires explicit programmer intervention. I am not saying it should not be in the language. I am just saying that *as a tool for helping STUDENTS* it is inadequate (and it wasn't designed for that). The convention I mention is a tool for _avoiding_ initialisation errors, not a tool for checking them. What I want is static checkers (at _least_ as good as Lint or GCC checking for uninitialised variables, ideally a lot better because they are pretty weak) AND DYNAMIC CHECKERS. Yes, this is the old idea of a "checkout compiler" as opposed to an "optimising compiler". Yes, this is the kind of thing CodeCenter buys you for C. It has been a while since I used CodeCenter, but I remember vividly how very efficient a _debugging_ tool it was. Code didn't _run_ fast, but it certainly _found mistakes_ fast. And of course I want them free, yesterday. Our wonderful new Federal Government made election promises about maintaining funding for education and the 2000 Olympics. Well, the Olympics are safe, but they are now, only a couple of months after the election, talking about 10% education cuts. How this is supposed to make the education system "more competetive" escapes me; I believe politicians must be on drugs. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.