llvm dev - May 2019 - RFC: changing variable naming rules in LLVM codebase

Thanks very much for all the feedback. I've tried to collect the information
into a proposal for a transition plan: https://reviews.llvm.org/D59251.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190312/8c8a6961/attachment.html>

Wow, nice! Got here a bit late, but I'm happy we're finally taking this
leap. :)

I agree with lower case variable names, but don't mind much between
camel and underscores. I personally use both depending on the phase of
the moon, so...

I really dislike variable type separation, especially in a
quasi-strongly typed language where we normally declare the casts
intentionally.

Using auto should be done when the variable is transient or the type
is too complex, which would provide complex and confusing mangling for
the prefix.

I like the separation of "useful acronyms" and "unnecessary
one-letters" and I think your document has a lot of common sense.

Some may say we'll shortly incur into a battle of styles, but I think
that won't last long. Our community is stable enough for that kind of
petty behaviour to endure. :)

I agree with Chris to change what's needed, not a huge refactor. This
has a good number of precedents in LLVM and reduces the impact of
non-functional changes to a minimum. This is also more ameanable to
dowsntream repos.

Though, Rui's idea to do a bigger refactory in lld is brilliant, even
if a little stressfull. Again, we have precedent for big localised
changes and it mostly ends up as being good community work.

Thanks for pushing this, I agree the code ends up a bit dense, even in
places I am very familiar in, but haven't looked for a year, new
acronyms can make it hard to read. And if that increases the number of
new contributors, all the better!

cheers,
--renato

On Tue, 12 Mar 2019 at 13:31, Michael Platings via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Thanks very much for all the feedback. I’ve tried to collect the
information into a proposal for a transition plan:
https://reviews.llvm.org/D59251.
>
>
>
> -Michael
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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