[llvm-dev] changing variable naming rules in LLVM codebase
llvm-dev at lists.llvm.org
Wed Feb 13 08:52:28 PST 2019
> 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.
More information about the llvm-dev