On Thu, Mar 08, 2012 at 02:04:20PM -0500, Jonathan M Davis wrote: [...] > The names need to be good enough that the code is reasonably > understandable without necessarily having to look at the documentation > (though there's a good chance that you're still going to have to look > at the docs), and they should be good enough that most people have a > good chance of finding what they're looking for when they look for a > funcition or type in the docs. But there are so many variations on how > things can be named, and so many people expect different things, that > you're never going to win. At best, you please the majority. But names > are _always_ bikeshedding issues.
+1. > A _lot_ of what goes into symbol naming is personal preference and a > matter of what you've previously been exposed to rather than anything > objective, and there will pretty much always be disagreements on it. [...] That's true. Most of the abbreviations I've been comfortable with are those that I've learned when I was a teenage aspiring programmer. In retrospect, a lot of it makes no sense. I just preferred it that way 'cos that's the way I first learned it, and AFAICT at the time, that was the way it had *always* been (which is, of course, not true in retrospect). T -- Любишь кататься - люби и саночки возить.