Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: Fortran 77 Style Guide (long, REPOST) Message-ID: Date: 13 Sep 90 15:46:58 GMT References: <26B89BE1.4349@ics.uci.edu> <59012@lanl.gov> <1794@ccadfa.adfa.oz.au> <1990Sep10.141639.970@maverick.ksu.ksu.edu> Sender: news@skipper.dfrf.nasa.gov Distribution: na Organization: NASA Dryden, Edwards, Cal. Lines: 54 In-reply-to: mac@harris.cis.ksu.edu's message of 10 Sep 90 14:16:39 GMT On 10 Sep 90 14:16:39 GMT, mac@harris.cis.ksu.edu (Myron A. Calhoun) said: Myron> Unfortunately, re-used FORMATs cause programs to "break" during Myron> maintenance. The scenario is that someone modifies a FORMAT Myron> and ONE of its associated I/O statements but doesn't notice Myron> there are others. Myron> Voila! Instant "broken" program. Hmmm. I'd been tempted to make a very simillar point, but on the opposite side. The scenario is that two or more I/O statements each have separate but equal (where have I heard that phrase :-)) format statements. The time comes to change the format (in some way that doesn't require explicit change in the I/O statement. You change one format, but miss the other(s). Voila, "broken" program. Perhaps it can't read it's own files back in correctly. Myron> ...one thing I've learned is to NOT reuse FORMAT statements. I partly agree, but with some small quibbles. If two format statements are inherently required to be the same (a prime example being the format statements used to write and read the same data), then I think there should be only one format statement (where practical. If the read and write are in separate subroutines, this may not be practical, though I have at least one case where I put several formats in an include file to insure that they were the same in the read and write routines). I view this as a case of the general programming principle that you should avoid hidden dependencies between separate areas of code. If two pieces of code look identical and must remain identical, perhaps there should be only one piece of code, called as a subroutine or whatever. By the same token, I agree that it is detrimental to maintainability to combine 2 completely unrelated format statements that coincidentally happen to look the same in the current version of the code. That would be just as bad an idea as replacing every instance of the literal constant 10 with a PARAMETER named TEN. (Might well be a good idea to use parameters instead of the literal constants, but they should be named something more functionally obvious and those with different functions should have different names). Myron> .... I've learned a lot in 20 years ...not that I haven't made all of the mistakes alluded to above in my 20 years (sigh). Seems like there ought to be a better way to learn than by making all the mistakes myself :-(. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]