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: Ken Garlington Subject: Re: Coding Standards Date: 1996/05/29 Message-ID: <31AC0366.33F9@lmtas.lmco.com>#1/1 X-Deja-AN: 157355822 references: <9605151401.AA04364@most> <31AABC53.1080@lmtas.lmco.com> 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-29T00:00:00+00:00 List-Id: Robert A Duff wrote: > > >It also seems to me that your argument regarding the language manual is also > >deficient, in that it assumes that if requring knowledge from one source is > >necessary, that requiring knowledge from two sources is better. If that's the > >case, why not use obscure sequences of letters for all declarations, with a > >third document definining what these sequences actually mean? Generally, I > >would think the _less_ complicated you make the process of understanding and > >maintaining software, the better. > > OK, I call a truce in the effort to push each other's arguments to > logical extremes. ;-) I don't think you understand. The _core_ of my argument is that the code should be as self-explanatory as practical, to enhance (a) readability, (b) maintainability, and (c) reusability. I accept that there are limits to this goal; for example, that knowledge of the Ada standard is still required. In addition, for certain kinds of maintenance (major changes in architecture, for example), knowledge of the system requirements, etc. are also necessary. However, I'm still looking for a case where knowledge of the coding standard used during development is legitimately critical to long-term maintenace of the software. Without such a case, I don't see an obstacle to effective maintenance of code without reference to the original coding standard. > >This still begs the question I've asked on a couple of occasions: What > >happens when your code is used on my project? If I reuse your code, am > >I forced to use your coding standards, in order to keep the code maintainable? > >This would seem to be a significant deterrent to its reuse. > > I thought that (repeated) question was rhetorical. My only answer is, > "Yes, it's hard to interface project A to project B when the coding > standards are incompatible." Maybe that's one of the (many?) reasons > why Software Reuse hasn't really happened (at least, not to a great > enough extent to solve all the world's software problems). ;-) If the way we use coding standards inhibits reuse, then maybe it's worth looking at changing the way we write coding standards. Read on... > Maybe if we all *agreed* on coding standards, software reuse would be > easier. The industry is not mature enough for that, unfortunately. > (We can't even all agree on a single programming language, not even > within a single application area!) I still believe there is an alternative to requiring all projects to use a common coding standard. That alternative is to write the coding standard in such a way that it is not _required_ for maintenance. Again, the coding standard should be designed to make the code self-explanatory. Without a coding standard, there's no guarantee that this will happen. With a "good" coding standard, I think the code can be read, maintained, and reused without knowledge of the standard. This may sound paradoxical, but it makes sense to me. An imperfect analogy: Suppose I reuse Ada 83 code on an Ada 95 project. I would hope that the coding standard for the Ada 83 code included provisions to avoid Ada 95 incompatibilities. However, I should be able to maintain that Ada 83 code with my Ada 95 coding standard, without including a section on avoiding Ada 95 incompatibilities. Also, as I mentioned before, I think requiring knowledge of the coding standard to understand the code has consequences beyond reuse. I think it also limits the ability of the project to evolve the coding standard. Suppose, for example, the project upgrades to an Ada 95 compiler. That project will probably want to upgrade their coding standard. However, if the coding standard has within it the meaning of certain non-obvious conventions, the project has to be very careful not to change anything in the standard that will invalidate those conventions. On the other hand, if the coding standard is not needed to understand the code, this should not be as serious a concern. > > - Bob -- LMTAS - "Our Brand Means Quality"