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

[Neil Nelson via llvm-dev]

+1 for doing it all at once but with the following suggestion, which is 
basically that we need to manage the scale of issues that may crop up in 
a gradual manner.

Run the renaming program on the whole of the current latest stable code. 
That result can be uploaded and release-tested that will give a better 
idea of issues. That is, the issue rate for the changed code over the 
unchanged release code.

When the prior issue volume becomes acceptable, run the changed code in 
the buildbots to collect more issues.

When that issue volume becomes acceptable, the changed release becomes 
the latest release.

At that point those working on their own code copies can diff their 
changes to the release before the changed release. They can then run the 
renaming on their own code and diff that result to the changed release. 
Those two diffs should align and it would be nice to have a tool that 
could verify that, but the diff lengths should not be that hard to 
manually check.

Maintaining the new standard might be done by running the renaming on 
new submissions and counting the changes, with any changes recorded and 
provided to the author for correction.

Regards, Neil Nelson

On 7/18/19 7:09 PM, Chris Lattner via llvm-dev wrote:
>> On Jul 18, 2019, at 3:49 PM, Rui Ueyama via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>     And one more question:
>>
>>     What is the plan of renaming variables in llvm and clang? Will it
>>     be done gradually, i.e. directory by directory?
>>
>>
>> That's a big topic. I was thinking of starting a new thread just for 
>> that. Originally I was trying to do this directory-by-directory 
>> basis, but now I'm inclined to do this in a single extremely large 
>> patch. There's a risk of doing this that way (in particular, I'm not 
>> confident that I can keep the buildbots green or will be able to make 
>> them green in a timely manner after committing), but I think that 
>> will make downstream repo maintainer's work easier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190722/33def8ad/attachment.html>