<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 13, 2019 at 6:52 AM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chandler wrote:<br>
<br>
> FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that<br>
> style so something else. <br>
<br>
Presumably you are equally opposed to RegularCamelCase, because we already<br>
use *that* style for something else.<br></blockquote><div><br></div><div>I would be opposed to going through the very significant cost of *changing* the naming convention, merely to end up there.</div><div><br></div><div>The convention we already use has a huge advantage of already being relatively consistent.</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But really, objecting on the grounds that a given style is already used for<br>
function names is really a very weak argument.  IME function names are <br>
*incredibly* *hard* to confuse with anything else, because they *always* have <br>
surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it<br>
even conceivable that you might not instantly get that fooBar and getThingy<br>
are methods?  Therefore, using the same convention for some other kind of<br>
name is Not Confusing.<br></blockquote><div><br></div><div>I disagree FWIW... Lambdas (and callables generally) at the least make this ambiguous.</div><div><br></div><div>I think the fact that named things are called does not fully disambiguate what they are.</div><div><br></div><div>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.</div><div><br></div><div>[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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and *that*<br>
is a barrier to code-reading IME.  Even renaming it to `stuff` would help<br>
approximately zero percent. Parameter? Local? Class member? Global?  LLVM has <br>
incredibly few globals for other reasons, but using the same convention for <br>
locals and class members is a real problem for code-reading, especially code <br>
operating in methods for classes you're not super familiar with.<br>
<br>
I acknowledge that the current RFC doesn't propose a member naming convention<br>
different from other variables, but IMO it really ought to.  *That* is the<br>
distinction that would really help in reading unfamiliar code.<br></blockquote><div><br></div><div>I could see a lot of utility of this, but I do find it to be orthogonal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--paulr<br>
</blockquote></div></div>