Zachary Turner via llvm-dev
2019-Feb-19 15:24 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Regarding a plan for conversion, I'm keen to avoid perfect being the enemy > of better.It seems a bit early to discuss conversion given there’s not consensus on a style. For example: If we imagine that over time it evolves such that 50% of the variables have> been renamed to camelBack versions of the type names, then it will look > like this:This comment seems to assume that camelBack is the agreed upon style and all we need to do now is move forward, and I do not believe that to be the case -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/059363ca/attachment.html>
Alex Bradbury via llvm-dev
2019-Feb-19 15:43 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> wrote:> On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Regarding a plan for conversion, I'm keen to avoid perfect being the enemy of better. > > > It seems a bit early to discuss conversion given there’s not consensus on a style. For example:I see it a bit differently. The first question is "should we change the LLVM naming conventions". I view the plan for conversion as essential to answering this question - IMHO if we're going to live with mixed styles for years (which would be the case if there were no concerted conversion effort) then the advantages of changing naming convention are outweighed by the disadvantages by quite some way. So while I appreciate the desire to separate concerns, I find it difficult to do so in this case. Best, Alex
Michael Platings via llvm-dev
2019-Feb-19 15:45 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
> It seems a bit early to discuss conversion given there’s not consensus on a style.My reason for pushing the conversion conversation is that if it's decided that we want to clang-tidy everything then we have much more leeway in which style we use. If we allow conversion to happen organically, then for that to work we need to take into account the current style coexisting with the new style, whatever that may be. My fear is that if we insist on a big-bang transition then there will be sufficient opposition that we end up making no change at all. For that reason I favour allowing conversion to happen organically.> This comment seems to assume that camelBack is the agreed upon style and all we need to do now is move forwardNo, I don't believe it's agreed upon, sorry to give that impression. I see strong views on both sides. I just picked one for arguments sake.
Mehdi AMINI via llvm-dev
2019-Feb-19 16:25 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
On Tue, Feb 19, 2019 at 10:44 AM Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> wrote: > > On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> Regarding a plan for conversion, I'm keen to avoid perfect being the > enemy of better. > > > > > > It seems a bit early to discuss conversion given there’s not consensus > on a style. For example: > > I see it a bit differently. The first question is "should we change > the LLVM naming conventions". I view the plan for conversion as > essential to answering this question - IMHO if we're going to live > with mixed styles for years (which would be the case if there were no > concerted conversion effort) then the advantages of changing naming > convention are outweighed by the disadvantages by quite some wayNot much to add, just a +1 : this is exactly my view as well. -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/23aa8deb/attachment.html>
Michael Platings via llvm-dev
2019-Feb-19 16:42 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
Alex Bradbury <asb at lowrisc.org> wrote:> IMHO if we're going to live > with mixed styles for years (which would be the case if there were no > concerted conversion effort) then the advantages of changing naming > convention are outweighed by the disadvantages by quite some wayThe specific concern I've seen raised is that when writing code you'll need to check which form of variable name is used in a particular scope. Clearly this is a cost, but given that code is read many times more than it is written, I submit that this as a cost worth bearing for the sake of making it easy to write good variable names. If you see other costs then I'd be interested to know what those are.
Michael Platings via llvm-dev
2019-Feb-20 12:13 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
There's a tool git-hyper-blame [1] that's designed to work well with mass-refactoring commits. It could aid a big-bang transition if we added a .git-blame-ignore-revs file. It could also include IDs of previous NFC commits. Does this make a big bang refactoring more palatable? [1] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
Chris Lattner via llvm-dev
2019-Feb-20 17:07 UTC
[llvm-dev] RFC: changing variable naming rules in LLVM codebase
> On Feb 19, 2019, at 7:43 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> wrote: >> On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Regarding a plan for conversion, I'm keen to avoid perfect being the enemy of better. >> >> >> It seems a bit early to discuss conversion given there’s not consensus on a style. For example: > > I see it a bit differently. The first question is "should we change > the LLVM naming conventions". I view the plan for conversion as > essential to answering this question - IMHO if we're going to live > with mixed styles for years (which would be the case if there were no > concerted conversion effort) then the advantages of changing naming > convention are outweighed by the disadvantages by quite some way. So > while I appreciate the desire to separate concerns, I find it > difficult to do so in this case.I absolutely respect that position and concern, but there are other factors to consider. Let’s assume that we all agreed that a change was the right thing to do, and we were only concerned about the transition (just to simplify the discussion): 1) Transition cost can be used to argue against *any* global improvement to an existing codebase. The GCC community used this argument for many years arguing against moving to C++ from C. It is true that there will be a time of transition, but at some point in time, you just decide that the cost of a global mechanical change is worth it and you get to consistency. 2) Tremendous amounts of new code is being written, and lots of existing code is being touched. This provides opportunities to incrementally migrate. 3) The cost of inconsistency is low, because the affected declarations typically have local scope. Even the affected globals in LLVM are typically static within a file. This means that you don’t need a global index to go what is going on. Variables and functions are also often named quite different (e.g. functions often use imperative verbs). 4) The LLVM community and project is growing through new subprojects, new targets, and other new things, and holding back the “correct” thing in new subprojects because of legacy code in other parts of the project doesn’t make sense. That said, I understand that there is still controversy about whether making a change would improve the project, I just wanted to point out that if we converge on that, then we should consider what LLVM looks like 10 years from now, not just what it looks like 6 months from now. I for one don’t want to see LLVM stagnate, slow, and suffer because of legacy concerns. -Chris