Nemanja Ivanovic via llvm-dev
2019-Feb-14 13:02 UTC
[llvm-dev] changing variable naming rules in LLVM codebase
I have to agree with Paul that I think it is rather useful to have a naming convention that distinguishes class members from locals, etc. I'm not sure what that would look like, whether an m prefix for data members would be something others would entertain, but something that makes it clear would probably be useful. To use Paul's example, I think that mTheStuff vs. TheStuff makes it super easy to visually identify what this is. I imagine this wasn't mentioned in this thread or previously adopted because of some good reason I am not aware of. A more minor point about underscores vs camel case - what I like about camel case is that it generally keeps my fingers on the 3 rows of the keyboard I use the most. From an ergonomics perspective, I find typing a whole lot of underscores a bit unnatural. So since I find camel case easier to type and equally as readable, I would favour it over underscores. On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote:> There is of course some amount of llvm and clang code which already uses > initialLowerCaseNames for variable names too, contrary to the style guide. > I don't know how 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 anyway, when we could do one with actual tangible value. >> >> On Wed, Feb 13, 2019 at 8:52 AM <paul.robinson at sony.com> wrote: >> >>> Chandler wrote: >>> >>> > FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use >>> that >>> > style so something else. >>> >>> Presumably you are equally opposed to RegularCamelCase, because we >>> already >>> use *that* style for something else. >>> >>> But really, objecting on the grounds that a given style is already used >>> for >>> function names is really a very weak argument. IME function names are >>> *incredibly* *hard* to confuse with anything else, because they *always* >>> have >>> surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is >>> it >>> even conceivable that you might not instantly get that fooBar and >>> getThingy >>> are methods? Therefore, using the same convention for some other kind of >>> name is Not Confusing. >>> >>> OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and >>> *that* >>> is a barrier to code-reading IME. Even renaming it to `stuff` would help >>> approximately zero percent. Parameter? Local? Class member? Global? >>> LLVM has >>> incredibly few globals for other reasons, but using the same convention >>> for >>> locals and class members is a real problem for code-reading, especially >>> code >>> operating in methods for classes you're not super familiar with. >>> >>> I acknowledge that the current RFC doesn't propose a member naming >>> convention >>> different from other variables, but IMO it really ought to. *That* is >>> the >>> distinction that would really help in reading unfamiliar code. >>> --paulr >>> >> _______________________________________________ >> 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/20190214/8add1239/attachment.html>
Zachary Turner via llvm-dev
2019-Feb-14 16:02 UTC
[llvm-dev] changing variable naming rules in LLVM codebase
fwiw, LLDB also uses m_ for member variables, so if we were to adopt an m prefix, then in conjunction with lowercase_underscore the entire codebase would be conforming. On Thu, Feb 14, 2019 at 5:02 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote:> I have to agree with Paul that I think it is rather useful to have a > naming convention that distinguishes class members from locals, etc. I'm > not sure what that would look like, whether an m prefix for data members > would be something others would entertain, but something that makes it > clear would probably be useful. To use Paul's example, I think that > mTheStuff vs. TheStuff makes it super easy to visually identify what this > is. I imagine this wasn't mentioned in this thread or previously adopted > because of some good reason I am not aware of. > A more minor point about underscores vs camel case - what I like about > camel case is that it generally keeps my fingers on the 3 rows of the > keyboard I use the most. From an ergonomics perspective, I find typing a > whole lot of underscores a bit unnatural. So since I find camel case easier > to type and equally as readable, I would favour it over underscores. > > On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There is of course some amount of llvm and clang code which already uses >> initialLowerCaseNames for variable names too, contrary to the style guide. >> I don't know how 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 anyway, when we could do one with actual tangible value. >>> >>> On Wed, Feb 13, 2019 at 8:52 AM <paul.robinson at sony.com> wrote: >>> >>>> Chandler wrote: >>>> >>>> > FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use >>>> that >>>> > style so something else. >>>> >>>> Presumably you are equally opposed to RegularCamelCase, because we >>>> already >>>> use *that* style for something else. >>>> >>>> But really, objecting on the grounds that a given style is already used >>>> for >>>> function names is really a very weak argument. IME function names are >>>> *incredibly* *hard* to confuse with anything else, because they >>>> *always* have >>>> surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` >>>> is it >>>> even conceivable that you might not instantly get that fooBar and >>>> getThingy >>>> are methods? Therefore, using the same convention for some other kind >>>> of >>>> name is Not Confusing. >>>> >>>> OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and >>>> *that* >>>> is a barrier to code-reading IME. Even renaming it to `stuff` would >>>> help >>>> approximately zero percent. Parameter? Local? Class member? Global? >>>> LLVM has >>>> incredibly few globals for other reasons, but using the same convention >>>> for >>>> locals and class members is a real problem for code-reading, especially >>>> code >>>> operating in methods for classes you're not super familiar with. >>>> >>>> I acknowledge that the current RFC doesn't propose a member naming >>>> convention >>>> different from other variables, but IMO it really ought to. *That* is >>>> the >>>> distinction that would really help in reading unfamiliar code. >>>> --paulr >>>> >>> _______________________________________________ >>> 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/20190214/f72da2d2/attachment.html>
Kristof Beyls via llvm-dev
2019-Feb-18 15:00 UTC
[llvm-dev] changing variable naming rules in LLVM codebase
Op do 14 feb. 2019 om 14:02 schreef Nemanja Ivanovic via llvm-dev < llvm-dev at lists.llvm.org>:> I have to agree with Paul that I think it is rather useful to have a > naming convention that distinguishes class members from locals, etc. I'm > not sure what that would look like, whether an m prefix for data members > would be something others would entertain, but something that makes it > clear would probably be useful. To use Paul's example, I think that > mTheStuff vs. TheStuff makes it super easy to visually identify what this > is. I imagine this wasn't mentioned in this thread or previously adopted > because of some good reason I am not aware of. >+1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190218/9f921159/attachment.html>
David Greene via llvm-dev
2019-Feb-19 01:14 UTC
[llvm-dev] changing variable naming rules in LLVM codebase
That's interesting because I have always thought it strange to name members differently from other variables. I guess in my mind if a local variable isn't easily identified as such, it's either declared much too far away from its use (the function is too large, is lacking proper scoping, whatever) or it is not well-named such as to denote its use. Note that I specifically write, "denote its use" and not, "denote its scope." Of course the poor naming could go the other way; naming a member "i," for example. I don't think I've ever come across a naming convention that treats function parameters specially. Why? Arguably they are as different from locals as members are, particularly when it comes to reference parameters. Slapping an "m_" in front of poorly-named members isn't really going to help much, any more than slapping an "l_" in front of local variables would. That said, I am certainly open to being convinced otherwise. -David ________________________________________ From: Nemanja Ivanovic <nemanja.i.ibm at gmail.com> Sent: Thursday, February 14, 2019 7:02:19 AM To: James Y Knight Cc: Zachary Turner; David Greene; llvm-dev Subject: Re: [llvm-dev] changing variable naming rules in LLVM codebase I have to agree with Paul that I think it is rather useful to have a naming convention that distinguishes class members from locals, etc. I'm not sure what that would look like, whether an m prefix for data members would be something others would entertain, but something that makes it clear would probably be useful. To use Paul's example, I think that mTheStuff vs. TheStuff makes it super easy to visually identify what this is. I imagine this wasn't mentioned in this thread or previously adopted because of some good reason I am not aware of. A more minor point about underscores vs camel case - what I like about camel case is that it generally keeps my fingers on the 3 rows of the keyboard I use the most. From an ergonomics perspective, I find typing a whole lot of underscores a bit unnatural. So since I find camel case easier to type and equally as readable, I would favour it over underscores. On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: There is of course some amount of llvm and clang code which already uses initialLowerCaseNames for variable names too, contrary to the style guide. I don't know how 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<mailto: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 anyway, when we could do one with actual tangible value. On Wed, Feb 13, 2019 at 8:52 AM <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote: Chandler wrote:> FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that > style so something else.Presumably you are equally opposed to RegularCamelCase, because we already use *that* style for something else. But really, objecting on the grounds that a given style is already used for function names is really a very weak argument. IME function names are *incredibly* *hard* to confuse with anything else, because they *always* have surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it even conceivable that you might not instantly get that fooBar and getThingy are methods? Therefore, using the same convention for some other kind of name is Not Confusing. OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and *that* is a barrier to code-reading IME. Even renaming it to `stuff` would help approximately zero percent. Parameter? Local? Class member? Global? LLVM has incredibly few globals for other reasons, but using the same convention for locals and class members is a real problem for code-reading, especially code operating in methods for classes you're not super familiar with. I acknowledge that the current RFC doesn't propose a member naming convention different from other variables, but IMO it really ought to. *That* is the distinction that would really help in reading unfamiliar code. --paulr _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto: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<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Chandler Carruth via llvm-dev
2019-Feb-19 01:24 UTC
[llvm-dev] changing variable naming rules in LLVM codebase
Also FWIW, I also like m_ prefix for member variables when combined with lowercase_underscore naming. *IF* it is worth going through the significant cost of switching, and we have a plan to minimize the cost to developers reading inconsistent code. On Thu, Feb 14, 2019 at 6:03 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> fwiw, LLDB also uses m_ for member variables, so if we were to adopt an m > prefix, then in conjunction with lowercase_underscore the entire codebase > would be conforming. > > On Thu, Feb 14, 2019 at 5:02 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> > wrote: > >> I have to agree with Paul that I think it is rather useful to have a >> naming convention that distinguishes class members from locals, etc. I'm >> not sure what that would look like, whether an m prefix for data members >> would be something others would entertain, but something that makes it >> clear would probably be useful. To use Paul's example, I think that >> mTheStuff vs. TheStuff makes it super easy to visually identify what >> this is. I imagine this wasn't mentioned in this thread or previously >> adopted because of some good reason I am not aware of. >> A more minor point about underscores vs camel case - what I like about >> camel case is that it generally keeps my fingers on the 3 rows of the >> keyboard I use the most. From an ergonomics perspective, I find typing a >> whole lot of underscores a bit unnatural. So since I find camel case easier >> to type and equally as readable, I would favour it over underscores. >> >> On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> There is of course some amount of llvm and clang code which already uses >>> initialLowerCaseNames for variable names too, contrary to the style guide. >>> I don't know how 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 anyway, when we could do one with actual tangible value. >>>> >>>> On Wed, Feb 13, 2019 at 8:52 AM <paul.robinson at sony.com> wrote: >>>> >>>>> Chandler wrote: >>>>> >>>>> > FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use >>>>> that >>>>> > style so something else. >>>>> >>>>> Presumably you are equally opposed to RegularCamelCase, because we >>>>> already >>>>> use *that* style for something else. >>>>> >>>>> But really, objecting on the grounds that a given style is already >>>>> used for >>>>> function names is really a very weak argument. IME function names are >>>>> *incredibly* *hard* to confuse with anything else, because they >>>>> *always* have >>>>> surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` >>>>> is it >>>>> even conceivable that you might not instantly get that fooBar and >>>>> getThingy >>>>> are methods? Therefore, using the same convention for some other kind >>>>> of >>>>> name is Not Confusing. >>>>> >>>>> OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and >>>>> *that* >>>>> is a barrier to code-reading IME. Even renaming it to `stuff` would >>>>> help >>>>> approximately zero percent. Parameter? Local? Class member? Global? >>>>> LLVM has >>>>> incredibly few globals for other reasons, but using the same >>>>> convention for >>>>> locals and class members is a real problem for code-reading, >>>>> especially code >>>>> operating in methods for classes you're not super familiar with. >>>>> >>>>> I acknowledge that the current RFC doesn't propose a member naming >>>>> convention >>>>> different from other variables, but IMO it really ought to. *That* is >>>>> the >>>>> distinction that would really help in reading unfamiliar code. >>>>> --paulr >>>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ > 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/20190218/448a0d59/attachment.html>
James Henderson via llvm-dev
2019-Feb-19 10:34 UTC
[llvm-dev] changing variable naming rules in LLVM codebase
+1 to David's statement that naming members and locals differently seems strange to me. I can't think of a case where it's been important for me to distinguish between a local and class member and it hasn't already been clear at a glance/click etc. Frankly, I just find turning things into non-English words (e.g. due to a prefix/suffix) strange and makes it harder for me to actually read/talk about code with people in person etc (e.g. try talking about the theoretical member variable mThing/m_thing with someone). On Tue, 19 Feb 2019 at 01:15, David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote:> That's interesting because I have always thought it strange to name > members differently > from other variables. I guess in my mind if a local variable isn't easily > identified as such, > it's either declared much too far away from its use (the function is too > large, is lacking > proper scoping, whatever) or it is not well-named such as to denote its > use. Note that > I specifically write, "denote its use" and not, "denote its scope." Of > course the poor > naming could go the other way; naming a member "i," for example. > > I don't think I've ever come across a naming convention that treats > function parameters > specially. Why? Arguably they are as different from locals as members > are, particularly > when it comes to reference parameters. > > Slapping an "m_" in front of poorly-named members isn't really going to > help much, any > more than slapping an "l_" in front of local variables would. > > That said, I am certainly open to being convinced otherwise. > > -David > > ________________________________________ > From: Nemanja Ivanovic <nemanja.i.ibm at gmail.com> > Sent: Thursday, February 14, 2019 7:02:19 AM > To: James Y Knight > Cc: Zachary Turner; David Greene; llvm-dev > Subject: Re: [llvm-dev] changing variable naming rules in LLVM codebase > > I have to agree with Paul that I think it is rather useful to have a > naming convention that distinguishes class members from locals, etc. I'm > not sure what that would look like, whether an m prefix for data members > would be something others would entertain, but something that makes it > clear would probably be useful. To use Paul's example, I think that > mTheStuff vs. TheStuff makes it super easy to visually identify what this > is. I imagine this wasn't mentioned in this thread or previously adopted > because of some good reason I am not aware of. > A more minor point about underscores vs camel case - what I like about > camel case is that it generally keeps my fingers on the 3 rows of the > keyboard I use the most. From an ergonomics perspective, I find typing a > whole lot of underscores a bit unnatural. So since I find camel case easier > to type and equally as readable, I would favour it over underscores. > > On Wed, Feb 13, 2019 at 11:03 PM James Y Knight via llvm-dev < > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > There is of course some amount of llvm and clang code which already uses > initialLowerCaseNames for variable names too, contrary to the style guide. > I don't know how 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<mailto: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 anyway, when we could do one with actual tangible value. > > On Wed, Feb 13, 2019 at 8:52 AM <paul.robinson at sony.com<mailto: > paul.robinson at sony.com>> wrote: > Chandler wrote: > > > FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that > > style so something else. > > Presumably you are equally opposed to RegularCamelCase, because we already > use *that* style for something else. > > But really, objecting on the grounds that a given style is already used for > function names is really a very weak argument. IME function names are > *incredibly* *hard* to confuse with anything else, because they *always* > have > surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it > even conceivable that you might not instantly get that fooBar and getThingy > are methods? Therefore, using the same convention for some other kind of > name is Not Confusing. > > OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and > *that* > is a barrier to code-reading IME. Even renaming it to `stuff` would help > approximately zero percent. Parameter? Local? Class member? Global? LLVM > has > incredibly few globals for other reasons, but using the same convention for > locals and class members is a real problem for code-reading, especially > code > operating in methods for classes you're not super familiar with. > > I acknowledge that the current RFC doesn't propose a member naming > convention > different from other variables, but IMO it really ought to. *That* is the > distinction that would really help in reading unfamiliar code. > --paulr > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto: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<mailto: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/20190219/de70aa7d/attachment.html>