On Mar 8, 2013, at 6:25 PM, Richard Smith <[email protected]> wrote:
> On Fri, Mar 8, 2013 at 5:39 PM, John McCall <[email protected]> wrote:
> On Mar 8, 2013, at 5:13 PM, Chandler Carruth <[email protected]> wrote:
>> On Fri, Mar 8, 2013 at 5:07 PM, John McCall <[email protected]> wrote:
>> Oh, I must have.
>>
>>> Several more of your recent commits have converted variables from the
>>> InitialCaps style required by the coding standard to an initialLowercase
>>> form.
>>
>> Oh, did that get formalized? That's unfortunate for quite a few reasons.
>> Maybe LLVM is consistent about it, but Clang's code base is pretty far from
>> that, particularly in IR-gen.
>>
>> It did, and it is much more consistent in LLVM and other parts of Clang. Not
>> really endorsing it, but I figure we should all suffer through it or get
>> Chris to change it. ;]
>
> How's that reformatting tool coming along? :)
>
> I believe a tool to "fix" variable capitalization already exists, maybe
> Manuel can confirm that?
>
> I mean, there's also mass inconsistency in LLVM and Clang about
> capitalization of methods. Or rather, there isn't: I would estimate that
> LLVM and Clang are ~90% consistent with a convention of capitalizing the
> first letter in a method name, and (1) that also contradicts the style guide
> and (2) it actually *matters* because everybody using that method has to be
> aware of it.
>
> [... some quick-and-dirty regexps later...]
>
> In include/llvm: 6275 methods starting [a-z], 1491 methods starting [A-Z]
> In include/clang: 5176 methods starting [a-z], 2884 methods starting [A-Z]
>
> So it looks like we're more consistent with the coding standard than with the
> opposite convention in our public interfaces. In headers in clang's lib/,
> we're somewhat the other way around: 438 starting [a-z], 669 starting [A-Z],
> and specifically in clang's lib/CodeGen, we have 244 [a-z], 345 [A-Z].
Hmm. Raw counts here are going to be dominated by get/set/is methods, which
(1) we're very consistent about lowercasing but (2) are a huge exception.
"Action" methods, like those that dominate Sema, Parser, CGF, and CGM, are
overwhelmingly uppercased — with CGF and CGM being less consistent, but only
because I'm personally okay with inconsistency if it means we're making
progress — a "better slouching towards heaven than marching heads-high to hell"
sort of thing, which I don't think is how sabre sees it.
LLVM uses free functions more than we do, and they're also basically
universally uppercased.
> These numbers aren't entirely accurate, since they don't cover the vast
> numbers of Visit*, Traverse*, and Transform* functions we generate with
> xmacros.
I don't know why that would change the count, actually — one of them apiece
counts as source code.
> It seems clear to me that we're going to have a red letter day sooner or
> later where we rename a bunch of LLVM APIs, and if we do that, we should also
> change the local variable convention to something that LLVM contributors
> don't essentially universally dislike.
>
> Yes, I agree. I vaguely recall being told that the sticking point on this in
> the past was a worry about it degrading the usefulness of tools like 'svn
> annotate'. If we're no longer concerned about that, perhaps it's time to fix
> this once and for all.
This is unfortunately still a concern.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
