comp.lang.ada
 help / color / mirror / Atom feed
From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
Subject: Re: Coding Standards
Date: 1996/05/20
Date: 1996-05-20T00:00:00+00:00	[thread overview]
Message-ID: <4nppd5$61@goanna.cs.rmit.EDU.AU> (raw)
In-Reply-To: 319C52B2.36F6@lmtas.lmco.com


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 <garlingtonke@lmtas.lmco.com> 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.




  reply	other threads:[~1996-05-20  0:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-05-15  0:00 Coding Standards W. Wesley Groleau (Wes)
1996-05-15  0:00 ` Robert A Duff
1996-05-28  0:00   ` Ken Garlington
1996-05-28  0:00     ` Robert A Duff
1996-05-29  0:00       ` Ken Garlington
1996-05-30  0:00       ` Frank Manning
1996-05-28  0:00   ` Ken Garlington
1996-05-16  0:00 ` Ken Garlington
1996-05-17  0:00   ` Richard A. O'Keefe
1996-05-17  0:00     ` Ken Garlington
1996-05-20  0:00       ` Richard A. O'Keefe [this message]
1996-05-20  0:00         ` Ken Garlington
  -- strict thread matches above, loose matches on Subject: below --
1996-05-17  0:00 W. Wesley Groleau (Wes)
1996-05-28  0:00 ` Ken Garlington
1996-05-29  0:00 W. Wesley Groleau (Wes)
1996-05-29  0:00 ` Ken Garlington
1996-05-29  0:00 ` Robert A Duff
1997-09-17  0:00 Is there an ADA analogue to the C++ continue statement? Heath, Terry D.
1997-09-18  0:00 ` Pascal Obry
1997-09-19  0:00   ` Robert Dewar
     [not found]     ` <3422F037.41CA@lmco.com>
1997-09-20  0:00       ` dan13
1997-09-21  0:00         ` Robert Dewar
     [not found]           ` <3426B51E.7296@lmco.com>
1997-09-23  0:00             ` Coding Standards W. Wesley Groleau x4923
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox