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,6bd5598e439c30ef X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: explicit null Date: 1996/05/10 Message-ID: <31930D54.4837@lmtas.lmco.com>#1/1 X-Deja-AN: 154134705 references: <9605091727.AA01200@most> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.01 (Macintosh; I; 68K) Date: 1996-05-10T00:00:00+00:00 List-Id: Robert A Duff wrote: > > In article <9605091727.AA01200@most>, > W. Wesley Groleau (Wes) wrote: > >The chances of the above search occurring under deadline pressure are > >'null' :-) With no pressure, about 5%. ... > > You're correct, of course. In most projects, in most situations. > But it seems to me that this is an argument against having *any* coding > conventions beyond what the language RM actually requires. Actually, I think it's more of an argument for having coding conventions (related to communicating developer intent) that are a. Obvious as to the intent. b. As close as possible to the point where the information is needed. c. Not redundant with information that can reasonably be gleaned from code analysis tools. Coding standards that don't meet this criteria generally, in my experience, have two problems: (1) they tend to be used inconsistently/incorrectly by the developer, and (2) they tend to "drift" further off as the code is maintained. They usually end up causing more problems then they solve. -- LMTAS - "Our Brand Means Quality"