search for: lowercamelcased

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:

> On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Thu, Jul 5, 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

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 is not ideal.

> On Jul. 5, 2018, at 18:12, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 5, 2018 at 5:30 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

I would assume that the proper name in this case is constantExpr, and not CE. This is not really an acronym, but rather a shortcut taken for some unclear reason. > On 12. Feb 2019, at 13:02, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > >

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

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

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

> On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > > What would the recommendation be for acronyms (I’ve seen the rule about avoiding them unless they are “well known”, > but sometimes an acronym is useful, and we

...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

If we do add an argument to get(), then it should be named consistently with the ifnotfound argument of mget(). As mentioned, the possibility of a NULL value is problematic. One solution is a sentinel value that indicates an unbound value (like R_UnboundValue). But another idea (and one pretty similar to John's) is to follow the SYMSXP design at the C level, where there is a structure that

Adding an optional argument to get (and mget) like val <- get(name, where, ..., value.if.not.found=NULL ) (*) would be useful for many. HOWEVER, it is possible that there could be some confusion here: (*) can give a NULL because either x exists and has value NULL, or because x doesn't exist. If that matters, the user would need to be careful about specifying a value.if.not.found

On 08/01/2015 9:03 AM, John Nolan wrote: > Adding an optional argument to get (and mget) like > > val <- get(name, where, ..., value.if.not.found=NULL ) (*) That would be a bad idea, as it would change behaviour of existing uses of get(). What I suggested would not give a default. If the arg was missing, we'd get the old behaviour, if the arg was present, we'd use it.

On Mon, Jan 12, 2015 at 4:07 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > * 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

On Thu, 8 Jan 2015, Michael Lawrence wrote: > If we do add an argument to get(), then it should be named consistently > with the ifnotfound argument of mget(). As mentioned, the possibility of a > NULL value is problematic. One solution is a sentinel value that indicates > an unbound value (like R_UnboundValue). A null default is fine -- it's a default; if it isn't right for

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

> Adding an optional argument to get (and mget) like > val <- get(name, where, ..., value.if.not.found=NULL ) (*) > would be useful for many. HOWEVER, it is possible that there could be > some confusion here: (*) can give a NULL because either x exists and > has value NULL, or because x doesn't exist. If that matters, the user > would need to be careful about

On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: > On Thu, 8 Jan 2015, Michael Lawrence wrote: > > If we do add an argument to get(), then it should be named consistently >> with the ifnotfound argument of mget(). As mentioned, the possibility of a >> NULL value is problematic. One solution is a sentinel value that indicates >> an unbound value

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,