(original) (raw)
On Wed, Feb 13, 2019 at 6:52 AM <paul.robinson@sony.com> wrote:
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.
I would be opposed to going through the very significant cost of \*changing\* the naming convention, merely to end up there.
The convention we already use has a huge advantage of already being relatively consistent.
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.
I disagree FWIW... Lambdas (and callables generally) at the least make this ambiguous.
I think the fact that named things are called does not fully disambiguate what they are.
I'm not trying to say that the collision with functions is \*as\* confusing as that of colliding with types. Merely that both seem confusing. And I find \`foo\_bar\_baz\` and \`fooBarBaz\` basically equivalent\[1\]. So between those equivalents, I would choose the one with fewer collisions.
\[1\]: Ok, not quite, but I find this to be a more personal preference and am trying to weight it lower as a consequence. I find functions much more similar to types -- they are manifest properties of the program. I find \`FooBarBaz\` and \`fooBarBaz\` to be very similar looking. There is \*a\* distinction, but it is a minor one. I would prefer a greater visual difference for variables, which \`foo\_bar\_baz\` provides.
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.
I could see a lot of utility of this, but I do find it to be orthogonal.
\--paulr