Naming policies are always tricky. The one proposed by Hadley, as the one proposed by Google, are usable but not optimal according to most common 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. As always, this could be applied to new packages and to some extends to package upgrades What do you think of a such approach? Le ven. 9 août 2019 à 20:18, Ben Bolker <bbol...@gmail.com> a écrit : > > Creeping code complexity ... > > I like to think that the cuteR names will have a Darwinian > disadvantage in the long run. FWIW Hadley Wickham argues (rightly, I > think) against mixed-case names: > http://r-pkgs.had.co.nz/package.html#naming. I too am guilty of picking > mixed-case package names in the past. Extra credit if the package name > and the standard function have different cases! e.g. > glmmADMB::glmmadmb(), although (a) that wasn't my choice and (b) at > least it was never on CRAN and (c) it wasn't one of the cuteR variety. > > Bonus points for the first analysis of case conventions in existing > CRAN package names ... I'll start. > > > a1 <- rownames(available.packages()) > > cute <- "[a-z]*R[a-z]*" > > table(grepl(cute,a1)) > > FALSE TRUE > 12565 2185 > > > On 2019-08-09 2:00 p.m., neonira Arinoem wrote: > > 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, allowing strict compliance for new > > package names and lazy compliance for older ones. > > > > Doing so allows to enforce a new package name convention while also > > insuring continuity of compliance for already existing package names. > > > > Fabien GELINEAU alias Neonira > > > > Le ven. 9 août 2019 à 18:40, Kevin Wright <kw.s...@gmail.com> a écrit : > > > >> Please, no. I'd also like to disallow uppercase letters in package > names. > >> For instance, the cuteness of using a capital "R" in package names is > >> outweighed by the annoyance of trying to remember which packages use an > >> upper-case letter. > >> > >> On Thu, Aug 8, 2019 at 9:32 AM Jim Hester <james.f.hes...@gmail.com> > >> wrote: > >> > >>> Are there technical reasons that package names cannot be snake case? > >>> This seems to be enforced by `.standard_regexps()$valid_package_name` > >>> which currently returns > >>> > >>> "[[:alpha:]][[:alnum:].]*[[:alnum:]]" > >>> > >>> Is there any technical reason this couldn't be altered to accept `_` > >>> as well, e.g. > >>> > >>> "[[:alpha:]][[:alnum:]._]*[[:alnum:]]" > >>> > >>> I realize that historically `_` has not always been valid in variable > >>> names, but this has now been acceptable for 15+ years (since R 1.9.0 I > >>> believe). Might we also allow underscores for package names? > >>> > >>> Jim > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>> > >> > >> > >> -- > >> Kevin Wright > >> > >> [[alternative HTML version deleted]] > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
