On Wed, Jan 15, 2014 at 7:39 AM, jbiard <jbiard at mail.cicsnc.org> wrote:
> I don't think we should use ease of mapping variable names to a
> programming language as a reason for allowing (or not allowing) any
> particular character in variable names.
>
Why not? maybe not a compelling reason, but I can't imagine a compelling
reason to have more flexible naming conventions, either.
> CF has, as I understood it, considered variable names as completely up to
> the producer, relying on attributes to provide meaning. So, I can name a
> temperature variable "fluffy_bunny" if I want to, and it is completely
> valid.
>
valid yes, a good idea? probably not.
Section 1.3 of the Conventions states, "No variable or dimension names are
> standardized by this convention."
>
so there are no standard variable names -- that's not the same as standards
for variable names....
Personally, I wish there were standards for variable names, it would make
it easier to code against -- but that cat's out of the bag. But this cat
isn't: the restiricitons have been there for a long time, so the question
now is:
what are the reasons for easing those restrictions?
and
what are the reasons for keeping those restrictions?
we've given a few reasons for keeping them (maybe not all that compeling
toyou, but reasons none the less) -- what are the reasons for relaxing
them, other than "I like this naming convention that is currently not
allowed" ?
I'm not convinced that "fluffy-bunny" is any more readable or anything else
than "fluffy_bunny"
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140115/fb33b83f/attachment.html>
Received on Wed Jan 15 2014 - 10:00:08 GMT
