On Wed, Jan 15, 2014 at 7:39 AM, jbiard <[email protected]> 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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
