Re: Naming conventions?
From: Richard Maine (nospam_at_see.signature)
Date: 10/20/03
- Next message: Eric J. Kostelich: "Re: Reading CSV files"
- Previous message: José Rui Faustino de Sousa: "Re: Naming conventions?"
- In reply to: Andy: "Re: Naming conventions?"
- Next in thread: Paul van Delst: "Re: Naming conventions?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 20 Oct 2003 10:34:28 -0700
Andy <andy@ideafix.litec.csic.es> writes:
> I realize I have a name clash and was digging for a widely
> used convention to fix it. For example, "list_m" for modules, "list_t"
> for types and clean names for variables.
As Michel says, I don't think there is a single widely used convention.
I tend to make most of my type names end in _type. Its a little
wordy, but certainly clear and the type name doesn't get used so often
as to be a big problem. Your _t would work also if you like to keep
things a little shorter. I'd say that as long as you were internally
consistent about the convention (and don't have any contexts in which
a variable might "want" to end up with a _t standing for something
else), you should be fine.
My module names tend to be relatively long and descriptive. Thus,
they don't tend to need a _m, _mod, _module or whatever for
uniqueness. They are global names, so you don't want something sort
enough that conflicts are likely. Also, the only place yuo ever use
them is in USE statements (and you can only have one module per USE
statement), so a longish name doesn't much get in the way. Something
as short as "list" is awfully generic, even with a _m or something
similar appended. In f90/f95, pretty difficult to do a list-handling
module that is general enough for all lists (F2003 lets you do a
better job of that). So I'd tend to "decorate" the name a little
more... which will help if some of your code ever gets used in the
same project as some other code that has a different list module;
lists are generic enough that this seems quite plausible, at least for
my code.
Thus, in specific, I have a gd_list module for the lists that get
used in my getdata application. Prepending an application name
like that is something I do fairly often. For example, my pEst
(parameter estimation) program has modules with names including
pest_types, pest_plot, pest_options, pest_iterate, pest_integrate,
and the quite verbose pest_equations_of_motion.
All just to give a feel for my personal conventions. They are
neither universal nor obvuously better than anyone else's.
> Is there a reason module, type and variable names do not exist in
> their own name spaces? The module keyword, the brackets and :: would
> seem to be enough for the parser.
Type and variable names get mixed in ways that are not necessarily
easy to parse. For example, derived type constructors can look pretty
indistinguishable from function calls or array references. With
f2003, there are more places where type names can be used; I think the
new ones are probably all parsable as type names to the compiler, but
they would likely cause confusion to the human. So yes, I think there
are good reasons for not allowing type and variable names to conflict.
Module names are less clear. Their use is pretty restricted to the
extent that it would seem hard to confuse either the compiler or the
human. It would likely require some standard-speak wordsmithing to
keep the requirements that you'd still want, though. Just making
modules have their own namespace wouldn't quite do it. In particular,
you don't want module names to conflict with external procedure names
(because this would give compatibility headaches to some existing
implementations). But I'm sure the wordsmithing could be done without
major pain.
I think that for the module names, I'll have to fall back on the old
"because it didn't pass." Changes in that area have been proposed.
I don't recall all the exact proposals or the exact votes, but I
think it is safe to summarize it as "some people thought it should
be changed, but they failed to convince a majority."
I might hazard a *VERY* personal guess that the advocates of such
changes might have hurt their chances by appearing insensitive to the
potential problems (such as implementation compatibility issues with
allowing modules and externals to have the same names.) I think they
might have had better luck if they had proposed something with the
relatively minor restrictions necessary to take care of that. What I
vaguely recall is proposers who initially failed to even mention the
issue, and then responded that it either was unimportant or could be
fixed. If you are trying to sell something as trivial, it goes
over a lot better if you point out the potential issues and
solutions in the first place instead of appearing to have overlooked
them. It hurts credibility to be claiming that something is trivial
and has no impacts and then to have it pointed out that you
overlooked some issues, even if those issues do have reasonable
solutions.
Could be that my recollection of all the proposals is incomplete,
though. Perhaps someone did propose it all "just right" and still
failed to get a majority. If you think that there is any objective
validity to my speculations as to why something like this didn't
pass... I must be slacking in posting my "usual" disclaimer. :-)
-- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain | experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
- Next message: Eric J. Kostelich: "Re: Reading CSV files"
- Previous message: José Rui Faustino de Sousa: "Re: Naming conventions?"
- In reply to: Andy: "Re: Naming conventions?"
- Next in thread: Paul van Delst: "Re: Naming conventions?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
