Coding guidelines question
in [Fortran]
|
From: James Giles on 9 Mar 2006 14:49 Richard Edgar wrote: .... > I would also add that in one code I'm currently using, a USE statement > with ONLY tends to end up looking like > > USE MyModule, ONLY : MyModSubA, MyModSubB, MyModSubC, etc. > > I wouldn't say that ONLY should never be used, but the more I think > about it, the more of a hassle it seems to be in a good number of > cases. As I already mentioned. My own language works a little different. Apart from using different keywords, any USE of a module does not make the entities within that module directly visible. Instead the entities can only be referenced with "fully qualified names". So, if you say: USE MyModule ! or the equivalent, I don't have a USE keyword A public entity called STRIDE inside MyModule can't be referenced in the local scope except as MyModule%STRIDE. The only way to refer to STRIDE without a qualifier is to have (the equivalent of) an ONLY clause that lists STRIDE. If you always have ONLY clauses, the entities in a module cane be give mnemonic names for what they mean or do, not for where they are (which you always know anyway). In my earlier integer concatenate module, if I were to make the int_to_string procedure public, I'm not about to call it JLM_intcat_JLG_procedure_int_to_string. I'm going to leave with the name int_to_string. That describes what it does. If you need to know where it is (something you need to know, but more rarely), you can find that information in the declaration part of your local scope. -- 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 9 Mar 2006 21:05 James Giles wrote: > Rich Townsend wrote: > >>James Giles wrote: >> >>>The argument that people don't use ONLY because it's >>>too much trouble sound almost identical to the complaints >>>about IMPLICIT NONE. I still think everything visible >>>in a given scope should be declared there. For module >>>entities, all you have to declare is where they came from. >>>The ONLY clause declares the entities, and the corresponding >>>USE says where thay came from. That's hardly much of >>>a hardship. >> >>As an alternative, I make sure that in each module all of the public >>entities have the same prefix, which is unique across differing >>modules. >> >> Hence, I can always tell exactly where every routine, parameter, >>etc comes from --- and by looking at the actual code where these >>things are used, rather than having to look back at the ONLY clause. > > > I almost wrote a second paragraph in the above denouncing > that very practice. That means that all the entities from > modules have very verbose names (which I usually have > to rename anyway if I plan to use them several times - just > to avoid that problem). If legibility is important, using > novels as identifiers is counterproductive. Not to mention > overloaded operators - just a few days ago I posted an > overloaded concatenate operator. How do you propose > to name it so that you can tell what module it's from? Well, the one and only instance I've ever found operator overloading to be required was in my ISO_VARYING_STRING module -- and then, the naming was already specified by the standard. > > And, during code development, the proper packaging changes > from time to time. If I move an entity from one module to another, > but I'm using ONLY clauses, I merely have to change the module > name on the USE statement. If I have these verbose names that > contain the module name within them, I have to change every use > throughout the code. And, what of submodules? Do the names > of the entities have the parent's module name as part of their > own names? Or the submodule's name? Both? I don't have any submodules yet, since they are F2003 features. Regarding verbosity, the prefix is not the whole module name, just a two-character abbreviation. So it doesn't become really nastily wordy. > > Finally, if using an ONLY clause is a hardship, isn't writing > all those long names throughout the code even more of a hardship? > No, not for two-character prefixes. cheers, Rich
From: James Giles on 9 Mar 2006 21:50 Rich Townsend wrote: > James Giles wrote: .... >> And, during code development, the proper packaging changes >> from time to time. If I move an entity from one module to another, >> but I'm using ONLY clauses, I merely have to change the module >> name on the USE statement. If I have these verbose names that >> contain the module name within them, I have to change every use >> throughout the code. And, what of submodules? Do the names >> of the entities have the parent's module name as part of their >> own names? Or the submodule's name? Both? > > I don't have any submodules yet, since they are F2003 features. > Regarding verbosity, the prefix is not the whole module name, just a > two-character abbreviation. So it doesn't become really nastily wordy. And again: if you move an entity from one module to another, don't you have to rename throughout instead of just changing the module's name in the USE statement? If you need to know where something is from at each use of it, it seems to me you've already lost the namespace control effort. Any case, I still prefer ONLY clauses. *IF* (and it appears a big if) there is ever a way to selectively block host association, then having the USE statements only once in the module rather than within each procedure might be acceptable. Note that what I'm saying doesn't appear to be just my opinion. There were productivity experiments in the 70's to 80's that indicate that explicit import of each item you need rather than getting the whole module full increases productivity. The paper I still have a copy of is "Language Design for Programming Reliability", John Gannon and J. J. Horning, IEEE Transactions on Software Engineering, vol. se-1, no. 2, June 1975. This is a survey of several other papers. A large library nd a good citation index should enable you to find quite a collection of similar stuff. I've done that before. An important point is when they say "The right to access a name should be granted by mutual agreement between creator and accessor." It's hard to see that blanket import of the whole creator's wares qualifies. -- 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 9 Mar 2006 22:02 James Giles wrote: > Rich Townsend wrote: > >>James Giles wrote: > > ... > >>>And, during code development, the proper packaging changes >>>from time to time. If I move an entity from one module to another, >>>but I'm using ONLY clauses, I merely have to change the module >>>name on the USE statement. If I have these verbose names that >>>contain the module name within them, I have to change every use >>>throughout the code. And, what of submodules? Do the names >>>of the entities have the parent's module name as part of their >>>own names? Or the submodule's name? Both? >> >>I don't have any submodules yet, since they are F2003 features. >>Regarding verbosity, the prefix is not the whole module name, just a >>two-character abbreviation. So it doesn't become really nastily wordy. > > > And again: if you move an entity from one module to > another, don't you have to rename throughout instead > of just changing the module's name in the USE statement? Yes. This is one of the downsides of my approach. However, I don't tend to move entities around; for instance, I have a module that defines a cubic spline datatype, plus supporting routines; it would be unusual for any of this stuff to be moved to another module. Moves typically take place during the 'write one to throw away' prototyping stage, and not during general production-coding stages. > If you need to know where something is from at each > use of it, it seems to me you've already lost the namespace > control effort. Well, you had to know where it was in the first place, so that you could USE the appropriate module. > > Any case, I still prefer ONLY clauses. *IF* (and it appears > a big if) there is ever a way to selectively block host association, > then having the USE statements only once in the module rather > than within each procedure might be acceptable. > > Note that what I'm saying doesn't appear to be just my opinion. > There were productivity experiments in the 70's to 80's that > indicate that explicit import of each item you need rather > than getting the whole module full increases productivity. > The paper I still have a copy of is "Language Design for > Programming Reliability", John Gannon and J. J. Horning, > IEEE Transactions on Software Engineering, vol. se-1, > no. 2, June 1975. This is a survey of several other papers. > A large library nd a good citation index should enable > you to find quite a collection of similar stuff. I've done > that before. > > An important point is when they say "The right to access > a name should be granted by mutual agreement between > creator and accessor." It's hard to see that blanket import > of the whole creator's wares qualifies. > 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. :) cheers, Rich
From: James Giles on 9 Mar 2006 22:26
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.) -- 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 |