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,59d24b21703c2885 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Use of constants on EFA Date: 1997/11/05 Message-ID: #1/1 X-Deja-AN: 288176593 References: <63qkmc$8va$1@uttwil.bodensee.com> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 878790757 2500 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-11-05T00:00:00+00:00 List-Id: <> This is a very poor software design principle. Your coding practices are the appropriate ones. But as often happens, when someone puts a rule into a formal book, even if it is completely misguided as in this case, it tends to be taken by someone not in a position to evaluate the value of the rule as gospel. Note that at least in Ada 95, you do not have to declare constants to deal with the unconstrained cased, but of course it is still better practice to use the keyword constant wherever possible. Undoubtedly the rule was written by someone who did not appreciate the importance of the use of constant declarations in the manner in which you suggest. Probably the rule was intended to force the use of constant in appropriate situations, and it would be a surprise to the author of the rule to find it being used to *prevent* use of constant in appropriate situations. The proper rule for the use of constant in Ada is roughly, use constant on every object declaration, unless there is some reason that you cannot do so (i.e. there is some explicit or implicit assignment to the object). I find that most Ada programmers greatly underuse constant, partly because the syntax is a little heavy (*). It is most certainly sad to see a style guide insist on this poor practice. Keep up the fight to have this rule interpreted in a sensible manner. Particularly so, since, as you note, in Ada 83, the consequence of not being able to use a constant in the unconstrained case is extremely painful (indeed in Ada 83, the rule is, again probably unintentially, removing a critical piece of functionality from the code. It is a pity when people replace properly done quality assessment with simple comparisons to style books, but it happens all the time. Robert B.K. Dewar Ada Core Technologies (*) P.S. in Algol-68, the syntax for a constant is very light: variable int a; constant int a = 3; and so the use of constants is much more prevalent in A68 programs (the syntax for an initilaized variable is int a := 3; P.P.S. One very bad consequence of not using constant in the manner you suggest is that it greatly increases the maintenance burdens. If you follow this style guideline and write procedure x is y : integer := ... instead of procedure x is y : constant integer := ... you force the reader/maintainer to either search the entire procedure to look for an expected assignment to y (and to be irritated when none is found), or to read the code constantly worrying that y might be changing. Dynamic constants are an extremely important feature of a language like Ada. Forbidding them is seriously misguided. I do think you should try to dig into the origins of this rule. I am almost certain that the motiviation is to discourage people from failing to use constant on global values that do not change, in otherwords that an expected violation of this rule involves the failure to use the constant keyword.