[llvm-dev] changing variable naming rules in LLVM codebase

[via llvm-dev]

Chandler wrote:

> FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that
> style so something else. 

Presumably you are equally opposed to RegularCamelCase, because we already
use *that* style for something else.

But really, objecting on the grounds that a given style is already used for
function names is really a very weak argument.  IME function names are 
*incredibly* *hard* to confuse with anything else, because they *always* have 
surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it
even conceivable that you might not instantly get that fooBar and getThingy
are methods?  Therefore, using the same convention for some other kind of
name is Not Confusing.

OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and *that*
is a barrier to code-reading IME.  Even renaming it to `stuff` would help
approximately zero percent. Parameter? Local? Class member? Global?  LLVM has 
incredibly few globals for other reasons, but using the same convention for 
locals and class members is a real problem for code-reading, especially code 
operating in methods for classes you're not super familiar with.

I acknowledge that the current RFC doesn't propose a member naming convention
different from other variables, but IMO it really ought to.  *That* is the
distinction that would really help in reading unfamiliar code.
--paulr