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,7dd9b82cd363f55b X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Coding Standards Date: 1996/05/17 Message-ID: <4nh3n7$55g@goanna.cs.rmit.EDU.AU>#1/1 X-Deja-AN: 155276532 references: <9605151401.AA04364@most> <319B286E.3B2E@lmtas.lmco.com> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-05-17T00:00:00+00:00 List-Id: I liked initialised variables a lot, but I get to see rather more student code than my nerves can really cope with, and the 300th time you see n: Integer := 1; int n = 0; while n <= max loop while (n+1 <= max) { { n := n+1; ++n; end loop; } (Yes, the C is strangely indented, that's what I see.) you realise "it is important to group related things together", and "being able to move the first assignment up into the declarative region tempts many beginners to do it when they shouldn't". I've been looking for some guidelines, and I think that these are good: - constants MUST be initialised where they are declared X: constant Integer := ....; int const X = ...; (of course this doesn't apply to Ada deferred constants; give me credit for some sense.) - ALL variables must be initialised before they are used, WHETHER THE LANGUAGE WILL INITIALISE THEM OR NOT. This means I don't _care_ what Ada initialises pointers to, and I don't care what C initialises top-level variables to either. - other things being equal, the initialisation of a variable should be as late as possible. - other things being equal, the initialisation of a variable should be as close to its uses in the text as possible, so that when looking at the uses, the initialisation is visible. 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. I would also like to point out that in this year's C class, the second biggest cause of run-time errors (after the obvious biggie: design errors) was uninitialised variables. The lucky students were the ones where this resulted in a NULL pointers that were caught by the hardware. Students keep on telling me their program "works" when they really mean that Turbo C failed to notice the problem most of the time. (They are actually required to compile their programs on a SPARC/Solaris system, which is when they start complaining that 'cc' or 'gcc' is "broken".) 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. For developing large long-lived software systems where performance is an issue, the tradeoffs are different. -- 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.