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,8c87bf30faa2b6b X-Google-Attributes: gid103376,public From: mjp@itd.dsto.gov.au Subject: Re: [Q] To initialise or not. Date: 1996/04/30 Message-ID: <4m3se4$uda@fang.dsto.defence.gov.au>#1/1 X-Deja-AN: 152359677 references: <484274071wnr@diphi.demon.co.uk> <318109B1.3B54AFBF@escmail.orl.mmc.com> <75602294@dorunth.hb.north.de> organization: Defence Science & Technology Organisation newsgroups: comp.lang.ada Date: 1996-04-30T00:00:00+00:00 List-Id: "Thorsten Behrens" writes: >I tend to give all my declarations some initial value (if possible) _and_ >an initial comment (giving a shorter or longer text about its usage and >the background of this variable). In my eyes this saves me from having >non-initialized variables (causing errors which are sometimes nasty to >find) and it saves people reviewing my sources from wasting too much time >to guess what I was thinking when "inventing" a variable (normally, I would >not use a variable called 'X', but instead would have called it >'Some_Meaningful_Name'). I think what to do depends on the strenght of your compiler. Ideally, the hardware would have store both a value, and a bit indicating whether the value was valid (initialised) or not. If this hardware support is not provided, hopefully, your compiler will do a dataflow analysis and flag "used but not set" variables, even this can fail in things like loops or assignments in conditionals. I always prefer to force a detectable error so for instance I would tend to initialise to an absurd value. E.g. for a divisor variable, I would initialise to 0 in the declarations, that way if it is used before set it will cause a divide by zero exception. Of course not all operations will cause such obvious errors and in other cases I would tend to use such an out of bounds value that you would at least see the error in the output and go looking for it. The really insidious errors are the ones that don't look like a problem, i.e. appear plausable. Michael -- On Australia is prohibited from redistributing this document in any way Dr Michael Pilling Phone: +61 8 259 7017 DSTO ITD/SE 171 Labs Fax: +61 8 259 5589 PO Box 1500, Salisbury SA 5108, Australia Michael.Pilling@dsto.defence.gov.au