search for: underscore_nam

I want to reiterate the benefit that underscore_names would bring. To be clear it's not my favorite style, but it does have a very concrete advantage which is that we have a very large subproject already using it. it doesn't make sense to do a purely aesthetic move that not everyone is going to agree on anyway, when we could do one with act...

FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that style so something else. One of the biggest advantages of changing the variable naming convention would be to differentiate variables from other constructs IMO, and that's the nature of many examples here. Using underscore_names for variables as Zach suggests would,, onhe other hand, be a significant improvement IMO. That said, all of these changes are pretty dramatic and expensive. I'm personally in favor but you'd want a *lot* of buy in from the community as well as some really good tooling I think to help peo...

...w to easily quantify how much. > > E.g. ParseGNUAttributes in clang/include/clang/Parse/Parser.h is one I > noticed. > > > On Wed, Feb 13, 2019 at 2:49 PM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I want to reiterate the benefit that underscore_names would bring. To be >> clear it's not my favorite style, but it does have a very concrete >> advantage which is that we have a very large subproject already using it. >> it doesn't make sense to do a purely aesthetic move that not everyone is >> going to agree on a...

It very much depends on what is following the code snippit. If the second "if" is guarding a substantial block of code, "constantExpr" might very well be a good name. Otherwise something like "cExpr" or "constExpr" might be fine. In the past when I have seen things like "CE" in the code, it's not always immediately clear to me what it is. I