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]. These numbers aren't entirely accurate, since they don't cover the vast numbers of Visit*, Traverse*, and Transform* functions we generate with xmacros. > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
