[Rd] Underscores in package names

[neonira Arinoem]

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 <bbolker using 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.stat using 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.hester using 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 using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >>
> >> --
> >> Kevin Wright
> >>
> >>         [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]