Coding guidelines question
in [Fortran]
|
From: James Giles on 10 Mar 2006 00:42 Rich Townsend wrote: .... > I'm interpolating variables relating to the internal structure of a > star. Some of these variables are guaranteed to vary smoothly, without > discontinuities (e.g., the pressure), and are therefore good > candidates for spline interpolation. Others can show discontinuities > (e.g., Brunt-Vaiasala frequency, which shows a trapezoidal-like peak > around the cores of massive stars), and require linear interpolation, > since splines would introduce ringing around the discontinuity. So, in other words the two procedures do something noticably different. You actually need different names. But, the names should be mnemonic for what the procedures do, not where they are. Those two-letter prefixes don't convey (to me anyway) what the actual differences between the procedures are. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
From: Rich Townsend on 10 Mar 2006 01:28 James Giles wrote: > Rich Townsend wrote: > ... > >>I'm interpolating variables relating to the internal structure of a >>star. Some of these variables are guaranteed to vary smoothly, without >>discontinuities (e.g., the pressure), and are therefore good >>candidates for spline interpolation. Others can show discontinuities >>(e.g., Brunt-Vaiasala frequency, which shows a trapezoidal-like peak >>around the cores of massive stars), and require linear interpolation, >>since splines would introduce ringing around the discontinuity. > > > So, in other words the two procedures do something > noticably different. Well, only in the sense of the type of interpolation they do. You actually need different names. > But, the names should be mnemonic for what the procedures > do, not where they are. Those two-letter prefixes don't > convey (to me anyway) what the actual differences between > the procedures are. > To me, they do -- because I know sl comes from the spline module, and ft from the ftable (function table) module. cheers, Rich
From: Paul Van Delst on 10 Mar 2006 11:26 Rich Townsend wrote: > James Giles wrote: > >> Rich Townsend wrote: >> ... >> >>> Well, I'm coming at things from a namespace standpoint. If each module >>> has a different prefixing scheme, then there's no need to worry about >>> namespace conflicts. Without the scheme (or some other approach), one >>> has to start using ONLY to do renaming -- and in my eyes that is a sin >>> before God. :) >> >> >> >> Well, I come at these things from the point of view >> of namespace management too. The only time I have >> more than one thing in a given scope with the same >> name is when it's generic. I tend to only use renaming >> for things from the dreaded "someone else's module". >> I have yet to need any prefix codes to tell me where >> things are from. Usually I don't care. If I do, I want >> very much to always be able to tell by looking at the >> local declarations. (I don't want to have to maintain >> a table of what prefix codes go with what module >> name either. I don't quite see how two letter prefixes >> can really be mnemonic.) >> > > Let me give a concrete example, and see if you can suggest how to go > about things using your approach (which I'm interested to hear about -- > if I can dump the prefixes with no consequences, then I'm all for it). > In my cubic spline module, there is a routine sl_interp_y(), which > performs spline interpolation on tabulated (ie, y vs. x) data. I also > have a module that provides a routine ft_interp_y() --- it does the same > operation, but uses linear interpolation instead of spline. > > If I dumped the prefixes, then these two procedures would clash via the > TKR rules. Now, I could merge the routines; but I'd rather keep all the > spline stuff in the spline module, and all of the linear stuff in the > linear module. Any thoughts? I also sometimes need to do both spline and linear interpolation in the same scope. However the way I packaged all that stuff up was to use a single module called "Interpolation" that contains Spline_Interpolate() and Polynomial_Interpolate() functions (where the latter has an optional order argument that defaults to linear interpolation). In my case, I don't have specific types defined for different types of interpolation and for both interpolation functions, the mandatory arguments are the same, input x, y, and xint, output yint. I also don't want to overload them to some generic name because when I look at the call I want to be able to determine what type of interpolation is being done (e.g. spline or poly). I guess one could package the spline and polynomial(linear) stuff separately, but I find having a single module is easier to grok -- all my interpolation methods are available to me via one USE (similar for my Integration module)[*]. At any stage in development of the application code I could switch the interpolation function call name and get a result. No need to change my USE statement (i.e. because of an ONLY clause). It seems to me the USE,ONLY: clause/productivity argument must have some threshold below which ONLY clauses decrease productivity (simple example like above) and above which they increase productivity (e.g. more complex code where protected namespace decreases debug time). cheers, paulv [*] I can understand separating out the spline and poly/linear interpolation into their own modules for their development, but for their use I would still USE only one module via a wrapper: MODULE Interpolation USE Spline_Interpolation USE Polynomial_Interpolation END MODULE Interpolation -- Paul van Delst CIMSS @ NOAA/NCEP/EMC
From: Pierre Asselin on 13 Mar 2006 12:12 Dan Nagle <dannagle(a)verizon.net> wrote: > Playing Devil's Advocate further, an unqualified private statement > in each module to prevent "leak-through" of names Thanks. I was wondering how to do that and I couldn't remember. > could be considered > the equivalent of the ubiquitous C construct > #ifndef FUBAR_H > #define FUBAR_H > > /* stuff from fubar.h */ > > #endif Not quite. That idiom is to *allow* fubar.h to be leaked from another header, the point being that it will leak only once. You must be thinking of /* public fubar stuff */ #ifdef FUBAR_PRIVATE_H /* fubar implementation bits, * including #includes of more headers */ #endif /* FUBAR_PRIVATE_H */ -- pa at panix dot com
From: Pierre Asselin on 13 Mar 2006 12:15
Richard Edgar <rge21(a)pas.rochester.edu> wrote: > Pierre Asselin wrote: >> [ USE, ONLY in each subroutine to have less to remember ] > 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, It should happen infrequently if you get it right on the first time. Otherwise, expect to redesign your modules in ways that affect the higher-level code -- that *simplify* the higher-level code, usually. -- pa at panix dot com |