> On Feb 2, 2019, at 8:18 PM, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi all, >> >> As application of the naming rules are currently under discussion [1] this seems like a good time to bring this up: >> >> The current variable naming rule [2] states: Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats). >> I'm a relatively new arrival to the LLVM codebase and I want to follow the rules wherever I can, but I humbly submit that this rule is suboptimal for readable code. >> The rationale given at the time this rule was added was "document the prevailing convention" [3]. > > I completely agree with you that our variable naming rule is broken. This discussion has been brought up before (e.g. http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html <http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html>) and hasn’t made any progress - people seem to not be willing to make a change, e.g. saying "the cure is worse than the disease". I’m personally in favor of Nick’s proposal (linked above) which makes variable names and function names be lower camel case.It’s worth noting that at the time, if I recall correctly, I argued against Nick’s proposal. I’m since come around to see the wisdom of his position and agree that we should have done it. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190202/96aa9eae/attachment.html>
IIRC the last time around there was strong agitation to make function names and variable names look different, which made no sense to me because their contextual syntax makes it blatantly obvious whether a name is a function or a variable. The only possible situation where you could be confused is assigning a function to a function-pointer, which in typical C++ basically you never do that. I'd much rather have a convention that did not treat all "variables" the same. Instead, distinguish variable names based on scope/lifetime; for example, it's common practice (outside of LLVM) for class data members to have a different/variant convention (trailing underscore, leading "m_") because that data all has a scope/lifetime far beyond the current method. Local variables and function parameters, by contrast, have comparatively limited scope. With no immediate visual clue to the difference, I find myself spending a fair amount of time paging around the source and trolling through headers trying to work out which is what. That is: I find the current convention not very readable. So, I'm quite happy to have camelCase for variables, but would also like some other distinction within the universe of variable names. Of course any change to existing conventions would cause some churn and confusion, but we *already* have that, as the current nominal conventions aren't in place in the entire codebase. Regarding snake_case, LLVM has very limited use of that, and only for things that are (a) substitutes or (b) extensions of STL features. "iterator_range" for example. camelCase predominates. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Saturday, February 02, 2019 11:19 PM To: Michael Platings Cc: llvm-dev at lists.llvm.org; nd Subject: Re: [llvm-dev] Variable names rule On Feb 2, 2019, at 8:18 PM, Chris Lattner <clattner at nondot.org<mailto:clattner at nondot.org>> wrote: On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi all, As application of the naming rules are currently under discussion [1] this seems like a good time to bring this up: The current variable naming rule [2] states: Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats). I'm a relatively new arrival to the LLVM codebase and I want to follow the rules wherever I can, but I humbly submit that this rule is suboptimal for readable code. The rationale given at the time this rule was added was "document the prevailing convention" [3]. I completely agree with you that our variable naming rule is broken. This discussion has been brought up before (e.g. http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html) and hasn’t made any progress - people seem to not be willing to make a change, e.g. saying "the cure is worse than the disease". I’m personally in favor of Nick’s proposal (linked above) which makes variable names and function names be lower camel case. It’s worth noting that at the time, if I recall correctly, I argued against Nick’s proposal. I’m since come around to see the wisdom of his position and agree that we should have done it. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/89413006/attachment.html>
On 04.02.19 15:20, via llvm-dev wrote:> I'd much rather have a convention that did not treat all "variables" the > same. Instead, distinguish variable names based on scope/lifetime;While it's not a very strong opinion, I'm actually fond of the fact that they're the same. The reason is that when you're implementing passes, whether a variable is local to the current method or a member of the class is really not a very meaningful distinction, and it's convenient to be able to change the scope occasionally as part of refactorings. IDEs are very good at jumping to variable declarations if there's any doubt. Cheers, Nicolai> for > example, it's common practice (outside of LLVM) for class data members > to have a different/variant convention (trailing underscore, leading > "m_") because that data all has a scope/lifetime far beyond the current > method. Local variables and function parameters, by contrast, have > comparatively limited scope. With no immediate visual clue to the > difference, I find myself spending a fair amount of time paging around > the source and trolling through headers trying to work out which is > what. That is: I find the current convention not very readable. > > So, I'm quite happy to have camelCase for variables, but would also like > some other distinction within the universe of variable names. > > Of course any change to existing conventions would cause some churn and > confusion, but we *already* have that, as the current nominal > conventions aren't in place in the entire codebase. > > Regarding snake_case, LLVM has very limited use of that, and only for > things that are (a) substitutes or (b) extensions of STL features. > "iterator_range" for example. camelCase predominates. > > --paulr > > *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of > *Chris Lattner via llvm-dev > *Sent:* Saturday, February 02, 2019 11:19 PM > *To:* Michael Platings > *Cc:* llvm-dev at lists.llvm.org; nd > *Subject:* Re: [llvm-dev] Variable names rule > > > > On Feb 2, 2019, at 8:18 PM, Chris Lattner <clattner at nondot.org > <mailto:clattner at nondot.org>> wrote: > > > > On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi all, > > As application of the naming rules are currently under discussion [1] > this seems like a good time to bring this up: > > The current variable naming rule [2] states: Variable names should be > nouns (as they represent state). The name should be camel case, and > start with an upper case letter (e.g. Leader or Boats). > > I'm a relatively new arrival to the LLVM codebase and I want to follow > the rules wherever I can, but I humbly submit that this rule is > suboptimal for readable code. > > The rationale given at the time this rule was added was "document the > prevailing convention" [3]. > > I completely agree with you that our variable naming rule is broken. > This discussion has been brought up before (e.g. > http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html) and > hasn’t made any progress - people seem to not be willing to make a > change, e.g. saying "the cure is worse than the disease". I’m > personally in favor of Nick’s proposal (linked above) which makes > variable names and function names be lower camel case. > > It’s worth noting that at the time, if I recall correctly, I argued > against Nick’s proposal. I’m since come around to see the wisdom of his > position and agree that we should have done it. > > -Chris > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte.
I so agree. I have found scope based coding conventions very useful. My favorite was: * Static data member: s_<lowerCaseLetterThenCamelCase> * Non-static data members: _<lowerCaseLetterThenCamelCase> (This was allowed by the C++ standard I last read. It’s _<UpperCase> that is reserved) * Function argments: <lowerCaseLetterThenCamelCase>_ * Function local variables: <lowerCaseLetterThenCamelCase> * Class/Struct identifiers: <UpperCaseLetterThenCamelCase> Even “smart” IDE’s can become confused – I’ve tried several (all “free”, open source) on the LLVM code base, and they’ve all failed, either finding the wrong thing (that has the same identifier) or not finding the thing (when it most definitely does exist). If someone knows of a (“free”) IDE that does not get confused by the LLVM code base, please, please advise? Many thanks! From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via llvm-dev Sent: Monday, February 4, 2019 8:21 AM To: clattner at nondot.org; Michael.Platings at arm.com Cc: llvm-dev at lists.llvm.org; nd at arm.com Subject: Re: [llvm-dev] Variable names rule Importance: Low IIRC the last time around there was strong agitation to make function names and variable names look different, which made no sense to me because their contextual syntax makes it blatantly obvious whether a name is a function or a variable. The only possible situation where you could be confused is assigning a function to a function-pointer, which in typical C++ basically you never do that. I'd much rather have a convention that did not treat all "variables" the same. Instead, distinguish variable names based on scope/lifetime; for example, it's common practice (outside of LLVM) for class data members to have a different/variant convention (trailing underscore, leading "m_") because that data all has a scope/lifetime far beyond the current method. Local variables and function parameters, by contrast, have comparatively limited scope. With no immediate visual clue to the difference, I find myself spending a fair amount of time paging around the source and trolling through headers trying to work out which is what. That is: I find the current convention not very readable. So, I'm quite happy to have camelCase for variables, but would also like some other distinction within the universe of variable names. Of course any change to existing conventions would cause some churn and confusion, but we *already* have that, as the current nominal conventions aren't in place in the entire codebase. Regarding snake_case, LLVM has very limited use of that, and only for things that are (a) substitutes or (b) extensions of STL features. "iterator_range" for example. camelCase predominates. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Saturday, February 02, 2019 11:19 PM To: Michael Platings Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> ; nd Subject: Re: [llvm-dev] Variable names rule On Feb 2, 2019, at 8:18 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org> > wrote: On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: Hi all, As application of the naming rules are currently under discussion [1] this seems like a good time to bring this up: The current variable naming rule [2] states: Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats). I'm a relatively new arrival to the LLVM codebase and I want to follow the rules wherever I can, but I humbly submit that this rule is suboptimal for readable code. The rationale given at the time this rule was added was "document the prevailing convention" [3]. I completely agree with you that our variable naming rule is broken. This discussion has been brought up before (e.g. http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html) and hasn’t made any progress - people seem to not be willing to make a change, e.g. saying "the cure is worse than the disease". I’m personally in favor of Nick’s proposal (linked above) which makes variable names and function names be lower camel case. It’s worth noting that at the time, if I recall correctly, I argued against Nick’s proposal. I’m since come around to see the wisdom of his position and agree that we should have done it. -Chris -- This message is intended for the addressee only and may contain Paragon Research Corporation (PRC) confidential or privileged information. Use or distribution of such confidential information is strictly prohibited without the prior written permission of PRC. If you have received this message in error, please contact the sender immediately and delete the message and attachments from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/9e2cd114/attachment.html>
> On Feb 4, 2019, at 9:20 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > IIRC the last time around there was strong agitation to make function names and variable names look different, which made no sense to me because their contextual syntax makes it blatantly obvious whether a name is a function or a variable. The only possible situation where you could be confused is assigning a function to a function-pointer, which in typical C++ basically you never do that. >I think it’s more important to distinguish types and variables. Variables should be lowercase and distinguished from uppercase types. For some reason it’s allowed to shadow types with variable names, so we end up with quite a bit of code using variable names like “Value” which is also a class. This is made worse by the fact that lldb doesn’t recognize this, so when you try to print “Value” it’s confused since that’s a type. I’ve wasted a lot of time renaming variables when debugging just to avoid this problem. I assume this has never been fixed since pretty much every other naming convention doesn’t uppercase variables. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/a111e900/attachment.html>