[llvm-dev] RFC: changing variable naming rules in LLVM codebase

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 4 21:50:05 PDT 2019


Hi all,

I wrote a tool <https://reviews.llvm.org/D64123> to batch-rename variable
names so that they are in camelCase, and I applied the tool to lld
subdirectory. You can see my change at https://reviews.llvm.org/D64121. If
you have any comments, please reply.

If people are happy about this change, I can do the same thing for other
directories including LLVM itself and Clang.

On Mon, Jun 10, 2019 at 6:34 PM Rui Ueyama <ruiu at google.com> wrote:

> On Mon, Jun 10, 2019 at 6:27 PM Michael Platings <Michael.Platings at arm.com>
> wrote:
>
>> Hi Rui,
>>
>>
>>
>> As per the provisional plan [1] we’re still at step 1: improving git
>> blame. The status of this is that there are some fairly mature patches in
>> the Git project’s queue [2], and I’m hopeful that it will be accepted in
>> something close to its current form.
>>
>>
>>
>> But if you can get started on steps 2 & 3 i.e. making forks available
>> with the possible changes applied then that would be great. My hope is that
>> once everyone can see what the options really look like then it will be
>> easier to reach consensus.
>>
>
> Sure, I'll try to do that. I'll probably start with finding identifiers
> and typenames that will conflict after the naming scheme change and rename
> them so that they won't conflict. The number of such symbols would
> hopefully be small, and submitting such renaming changes wouldn't be
> distracting. After that, I think I can create a mechanical change to rename
> variables to see how it will look like.
>
>
>>
>> Thanks,
>>
>> -Michael
>>
>>
>>
>> [1] https://llvm.org/docs/Proposals/VariableNames.html#provisional-plan
>>
>> [2]
>> https://public-inbox.org/git/20190515214503.77162-8-brho@google.com/T/
>>
>>
>>
>> *From:* Rui Ueyama <ruiu at google.com>
>> *Sent:* 07 June 2019 08:42
>> *To:* Chris Lattner <clattner at nondot.org>
>> *Cc:* Michael Platings <Michael.Platings at arm.com>;
>> llvm-dev at lists.llvm.org; nd <nd at arm.com>
>> *Subject:* Re: [llvm-dev] RFC: changing variable naming rules in LLVM
>> codebase
>>
>>
>>
>> This thread is not active for a while, but I'm still interested in seeing
>> a change.
>>
>>
>>
>> Reading through this thread, looks like we can agree that we want to
>> change the local variable naming scheme so that they start with a lowercase
>> letter. Besides that, there were discussions about lower_case, camelCase,
>> m_ prefix, and each argument seems as convincing as others. I'm not sure
>> what is the decision making process in a situation like this.
>>
>>
>>
>> I'd personally vote for changing local variables to start with a
>> lowercase letter and keep other naming conventions as-is to make it a
>> minimum change.
>>
>>
>>
>> As I stated before, I'm happy to make a change to lld to see how a naming
>> convention change will look like, but in order to do that I need to get at
>> least a rough consensus to do that. What is a way to proceed?
>>
>>
>>
>> On Sat, May 25, 2019 at 3:00 PM Chris Lattner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi Michael,
>>
>>
>>
>> I’m still very interested in seeing a change here.  If someone is
>> interested in seeing a codebase using the proposed camelBack convention for
>> variables names, the MLIR codebase is public
>> <https://github.com/tensorflow/mlir> and uses it.
>>
>>
>>
>> If you’re curious to see what this looks like in practice, there are lots
>> of examples in the codebase, here is an example .cpp file
>> <https://github.com/tensorflow/mlir/blob/master/lib/Transforms/LoopUnrollAndJam.cpp>
>> , here is another
>> <https://github.com/tensorflow/mlir/blob/master/lib/Parser/Parser.cpp>,
>> here is an example header
>> <https://github.com/tensorflow/mlir/blob/master/include/mlir/IR/Location.h>
>> .
>>
>>
>>
>>
>>
>> We are still working our way through open sourcing logistics (not all the
>> code is out yet), but we would still like to contribute at least parts of
>> this to LLVM if the project is interested.  [[This is just an FYI, not
>> itself a proposal yet - one will be coming when we’re ready.]]
>>
>>
>>
>> -Chris
>>
>>
>>
>>
>>
>> On May 21, 2019, at 3:01 AM, Michael Platings via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>
>>
>> Hi folks,
>>
>> Git is on its way to learning how to ignore commits, allowing us to do
>> variable renaming and other small refactorings without breaking git blame.
>>
>> It's like git-hyper-blame [1] but significantly more powerful as it uses
>> fuzzy matching to match lines, including lines that may have been split or
>> joined.
>>
>> A preview release of Git with this new feature is at:
>> https://github.com/mplatings/git/releases/tag/ignore-rev
>>
>> Some of you have told me that you already have to spend time running git
>> blame multiple times to look past uninteresting commits so I'd love for you
>> to give this feature a try and see if it helps you. Your feedback will be
>> very valuable.
>>
>> Thanks,
>> -Michael
>>
>> [1]
>> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190705/f298ef4d/attachment.html>


More information about the llvm-dev mailing list