search for: lowercamelcase

I argue we should spell C++ lambdas (and other function-like variables) like functions, not like variables. - Use verbs, not nouns. - Use lowerCamelCase. Here's a patch that implements the change to the coding standards: https://reviews.llvm.org/D48991 <https://reviews.llvm.org/D48991> Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201807...

...2018 at 12:57 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> I argue we should spell C++ lambdas (and other function-like variables) like functions, not like variables. >> >> - Use verbs, not nouns. > > I think I agree with this. > >> - Use lowerCamelCase. > > In lld we use UpperCamelCase, as they are technically not function names but variable names. Using lowerCamelCase for function pointers feels really weird to me, as they are really variables than functions to me. I also agree that this is weird either way because they are variables whe...

TL;DR: change the rule for variable names from UpperCamelCase to lowerCamelCase. Just to get wider visibility on this, I'm raising this again as an RFC, as suggested by Roman Lebedev. My original post from last week is here and gives a rationale: http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed to be general agreement that the status quo...

...ailto:dexonsmith at apple.com>> wrote: > >> I argue we should spell C++ lambdas (and other function-like variables) like functions, not like variables. > >> > >> - Use verbs, not nouns. > > > > I think I agree with this. > > > >> - Use lowerCamelCase. > > > > In lld we use UpperCamelCase, as they are technically not function names but variable names. Using lowerCamelCase for function pointers feels really weird to me, as they are really variables than functions to me. > > I also agree that this is weird either way because th...

...antExpr *CE = dyn_cast<ConstantExpr>(V)) > if (CE->getOpcode() == Instruction::GetElementPtr && > CE->getOperand(0)->isNullValue()) { > > In the above example, is the recommendation to use “ce” instead of “CE” now? Or should it be “cE”? > With lowerCamelCase one might think that “cE” is the correct one (although I personally think that one looks quite ugly). > > Maybe there should be an exception that variable names that start with an acronym still should start with an upper case letter? > > /Björn > > > From: llvm-dev <...

...(V)) >>> if (CE->getOpcode() == Instruction::GetElementPtr && >>> CE->getOperand(0)->isNullValue()) { >>> In the above example, is the recommendation to use “ce” instead >>> of “CE” now? Or should it be “cE”? >>> With lowerCamelCase one might think that “cE” is the correct one (although I personally think that one looks quite ugly). >>> Maybe there should be an exception that variable names that start >>> with an acronym still should start with an upper case letter? >>> /Björn >>> Fr...

After having read through this long thread, I'm having trouble spotting a case of someone saying lowerCamelCase variable names is a bad idea. Nick's original proposal looks good to me. What do we need to do to move forward here? Thanks, Greg On Tue, Oct 14, 2014 at 2:55 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 13, 2014, at 4:31 PM, Chandler Carruth <chandlerc at goo...

On 8 January 2015 at 19:46, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Jan 8, 2015 at 4:35 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> >> How do you feel about adding LLD to the LLVM repo? Could it follow >> the same path as the integrated assembler? That is, Clang keeps it >> off by default for each architecture until

...antExpr *CE = dyn_cast<ConstantExpr>(V)) > if (CE->getOpcode() == Instruction::GetElementPtr && > CE->getOperand(0)->isNullValue()) { > > In the above example, is the recommendation to use “ce” instead of “CE” now? Or should it be “cE”? > With lowerCamelCase one might think that “cE” is the correct one (although I personally think that one looks quite ugly). In most examples, you’d use something other than an initialism. I was the one who started the whole CE thing as a contraction of the type into something short, but there are almost always things...

...on needs, that are 1. Name a package 2. Name a class 3. Name a function 4. Name a parameter of a function 5. Name a variable My approach is the following 1. Package names should be made of lowercase characters, dash, dot and underscore 2. Class names are UpperCamelCased 3. Function names are lowerCamelCased 4. Function parameters are semantic names resulting from underscore separated lowerCamelCased function name, type acronym and length specification. 5. Variable should be snake case That way you can not confuse one for the other. This brings clear view, ease reading and speeds up implementation...

In November, we had a "bug repository conversation" with Peter Hagerty and myself: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16065 where the bug report title started with --->> "exists" is a bottleneck for dispatch and package loading, ... Peter proposed an extra simplified and henc faster version of exists(), and I commented > --- Comment #2

...ka "master branch") because I'd like to get > > public comments {RFC := Request For Comments}. > > > > I don't like the name -- I'd prefer getIfExists. As Baath (2012, R > Journal) pointed out, R names are very inconsistent in naming > conventions, but lowerCamelCase is the most common choice. Second most > common is period.separated, so an argument could be made for > get.if.exists, but there's still the possibility of confusion with S3 > methods, and users of other languages where "." is an operator find it a > little strange. >...

...; (the "R trunk" aka "master branch") because I'd like to get > public comments {RFC := Request For Comments}. > I don't like the name -- I'd prefer getIfExists. As Baath (2012, R Journal) pointed out, R names are very inconsistent in naming conventions, but lowerCamelCase is the most common choice. Second most common is period.separated, so an argument could be made for get.if.exists, but there's still the possibility of confusion with S3 methods, and users of other languages where "." is an operator find it a little strange. If you don't like lo...

...ka "master branch") because I'd like to get > > public comments {RFC := Request For Comments}. > > > > I don't like the name -- I'd prefer getIfExists. As Baath (2012, R > Journal) pointed out, R names are very inconsistent in naming > conventions, but lowerCamelCase is the most common choice. Second most > common is period.separated, so an argument could be made for > get.if.exists, but there's still the possibility of confusion with S3 > methods, and users of other languages where "." is an operator find it a > little strange. >...

...rote: > > * fix the coding style first. > > * check-all clean on a asan and msan build. > > * -DBUILD_SHARED_LIBS=ON works. > > I can take the ASan/MSan and build work. Fixing the coding style is > important, but must it be a gate? If so, can we push the patch for > lowerCamelCase local variables in the LLVM coding conventions before > there's a plan on how to transition the LLVM codebase? Wait, huh? I didn't think there was *any* consensus that this was the desired path forward. I think Rafael was just listing things that would need to happen *if* it were the...

...uot;) because I'd like to get >> > public comments {RFC := Request For Comments}. >> > >> >> I don't like the name -- I'd prefer getIfExists. As Baath (2012, R >> Journal) pointed out, R names are very inconsistent in naming >> conventions, but lowerCamelCase is the most common choice. Second most >> common is period.separated, so an argument could be made for >> get.if.exists, but there's still the possibility of confusion with S3 >> methods, and users of other languages where "." is an operator find it a >> littl...

...getOpcode() == Instruction::GetElementPtr && >> >>> CE->getOperand(0)->isNullValue()) { >> >>> In the above example, is the recommendation to use “ce” instead >> >>> of “CE” now? Or should it be “cE”? >> >>> With lowerCamelCase one might think that “cE” is the correct one >> (although I personally think that one looks quite ugly). >> >>> Maybe there should be an exception that variable names that start >> >>> with an acronym still should start with an upper case letter? >> >&...

...; aka "master branch") because I'd like to get > > public comments {RFC := Request For Comments}. > > > I don't like the name -- I'd prefer getIfExists. As Baath (2012, R > Journal) pointed out, R names are very inconsistent in naming > conventions, but lowerCamelCase is the most common choice. Second most > common is period.separated, so an argument could be made for > get.if.exists, but there's still the possibility of confusion with S3 > methods, and users of other languages where "." is an operator find it a > little strange. >...

...ke to get >>> > public comments {RFC := Request For Comments}. >>> > >>> >>> I don't like the name -- I'd prefer getIfExists. As Baath (2012, R >>> Journal) pointed out, R names are very inconsistent in naming >>> conventions, but lowerCamelCase is the most common choice. Second most >>> common is period.separated, so an argument could be made for >>> get.if.exists, but there's still the possibility of confusion with S3 >>> methods, and users of other languages where "." is an operator find it a &g...

Won't it be better to have a convention that allows lowercase, dash, underscore and dot as only valid characters for new package names and keep the ancient format validation scheme for older package names? This could be implemented by a single function, taking a strictNaming_b_1 parameter which defaults to true. Easy to use, and compliance results will vary according to the parameter value,