Coding guidelines question
in [Fortran]
|
From: Dan Nagle on 8 Mar 2006 10:37 Hello, Pierre Asselin wrote: <snip a bunch> > Playing Devil's Advocate, in C the tradition is to #include all headers > at file scope and to #include needed headers from headers. Transliterated > to Fortran, that would mean USE at module scope (contrary to what I said) > and single-module wrappers (as I said). Playing Devil's Advocate further, an unqualified private statement in each module to prevent "leak-through" of names could be considered the equivalent of the ubiquitous C construct #ifndef FUBAR_H #define FUBAR_H /* stuff from fubar.h */ #endif -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc.
From: Richard Edgar on 8 Mar 2006 10:45 Pierre Asselin wrote: >> Yes, I thought about that case, but in the end I tend towards consistency. I know that all >> the required USE statements will be at the top of the module, evne if only one module >> procedure in that module actually uses stuff from the USE modules. It's one less thing for >> me to remember. > > On the contrary, you now have to remember what procedures do *not* use what > modules and you have no easy way of cribbing that from the sources. What > happens if one of the lower-level modules is redesigned ? How do you > know what higher-level code needs to be updated ? I don't quite see what you mean there. If a lower-level module has been redesigned in such a way as to require high level code to change (which should be happening fairly infrequently, or the point of splitting into modules is lost....), then sure it's not subprograms within the module which will need changing. It's individual lines within those subprograms, and hence finding them will be a job for $EDITOR's search function. And even then, you'll probably be having the compiler whinge about some you forgot. Personally, putting USE statements in individual procedures would feel like having instructions which say 1) Tools: Hammer Hammer nails into A 2) Tools: Screwdriver Screw B onto C 3) Tools: Hammer Hammer nails from A into thing made in step (2) etc. If I'm going to have a list of tools, I'd rather see them all at the start, so I can go off and find them, rather than having to wade through the entire instruction list. My preference for USE statements is similar. Not every procedure in a module may call everything USEd, but the procedures are still related. If two procedures have completely (or even substantially) disjoint USE requirements, then there's a good chance they don't really belong in the same module anyway (IMO, at least ;-) ). Richard
From: Bil Kleb on 8 Mar 2006 19:45 Paul Van Delst wrote: > Hello, Hello. > I'm putting together some coding guidelines for review by folks here and > I'm gathering input from a bunch of sources. I want to get some other > people's opinions on a particular item. You may also want to Google the antithesis, e.g., http://c2.com/cgi/wiki?BadCodingStandards > In one set of guidelines regarding USE satements I came across the > recommendation to keep USE statements local and not to put them in the > module header. We did that, viz, http://fun3d.larc.nasa.gov/chapter-8.html#s3 coupled with requiring the ONLY qualifier to make people more cognizant of the dependencies they are injecting and to be able to quickly see exactly what a given module procedure needs. Our coding standards were supposed to emphasize communication through code[1], but I don't think they really hit the mark. I also think they are missing opening prepositional phrases beginning with "To", that would tell you the "why" behind them. (This is a suggested format for getting the "why" into our Subversion log messages.) The latter motivation violates YAGNI[2] in some respects: we envisioned a future where the combination of USE and ONLY would let us make design choices as to where a procedure should really be located, i.e., possibly in another module that better fit it's dependencies. We have never done this to my knowledge. Regards, -- Bil http://fun3d.larc.nasa.gov [1] See, e.g., http://c2.com/cgi/wiki?MeaningfulName [2] http://c2.com/cgi/wiki?YouArentGonnaNeedIt
From: Bil Kleb on 8 Mar 2006 19:50 Keith Refson wrote: > > In the context of a large multi-module development project it has been my > experience that unshielded USE statements in module headers can cause > compilers to break or misbehave. We've experienced this quite a bit, especially with Intel 8 and 9 series compilers. (Not all our legacy code has yet caught up with our conventions -- even after 6 years!) -- Bil http://fun3d.larc.nasa.gov
From: Catherine Rees Lay on 9 Mar 2006 05:06
One thing which really, really bugs me about USE statements is ONLY. It drives me completely spare when some routine intended to, say, print a set of information, has an ONLY clause in because at the time it was written it only printed integer and real information (say), but didn't need to print any logicals. I fail to see how putting ONLY in to exclude the logical-printing routine does anything for the structure of the code, and all it does is add work when you update the printing and now want to output some logicals as well. I much prefer code written so that you'd have a bare USE PRINTING, and then you don't have to worry about changing it to call another printing routine which was there all along. If ONLY tells you anything useful at all about the structure of the code (i.e. this routine only uses the printing routines of the module, not, say, the file i/o routines) then IMO you should actually put the structure in at the next level down. By having separate functionality in separate modules. Otherwise, modifying USE statements becomes such a common operation that you don't even stop to think about whether this is a sensible thing to do (say, adding an ONLY reference to print the logicals) or a messup of the code structure (say, adding a reference to a file i/o routine, or some calculation, in the middle of a printing subroutine). Modifying USE statements should, IMO, be something that is almost never done. Okay, off the soapbox now :-) Catherine. Paul Van Delst wrote: > Hello, > > I'm putting together some coding guidelines for review by folks here and > I'm gathering input from a bunch of sources. I want to get some other > people's opinions on a particular item. > > In one set of guidelines regarding USE satements I came across the > recommendation to keep USE statements local and not to put them in the > module header. > > This behaviour is the total opposite of what I do - I put all USE > statements as the very first statements in modules and /none/ in the > module procedures. I do so because, in my mind at least if not in > practice, each procedure in that module cannot logically reside anywhere > else but in that module so it makes no sense to repeat the exact same > USE statements throughout. Additionally, I like being able to determine > all the module's USE dependencies by looking in one place. > > So, without trying to start a "my way is better than your way" > to-and-fro, do other folks have an opinion? Is there an accepted reason > for doing something like keeping USE statements local to procedures? > Should the localisation of USE statements relate somehow to the module > structure? > > cheers, > > paulv > |