This package leans towards tidyverse/r-lib, so I think we should adopt at least the user-facing style conventions of that universe, most especially function names. I also think we should stick to our conventions such as commas at line starts rather than line ends, other things that have more-than-just-aesthetic justifications.
I think that means we should do the following, but eager for thoughts on this:
current divMultBreaks is a breaking function, so in harmony with e.g. scales::breaks_extended() and scales::breaks_log(), we should do breaks_divMult(). For this, I think using "divMult" as a camel-ized abbreviation is pretty good, even if this might offend some eyes? This is parallel with other usage e.g. label_divMult()
current limBreaks limits a vector of breaks, so maybe we want limit_breaks()?
for reasons I don't understand, in scales, the functions are blah_trans instead of trans_blah so although this seems internally inconsistent, I guess we should follow (i.e. nel_trans() instead of trans_nel() in current package)
This package leans towards tidyverse/r-lib, so I think we should adopt at least the user-facing style conventions of that universe, most especially function names. I also think we should stick to our conventions such as commas at line starts rather than line ends, other things that have more-than-just-aesthetic justifications.
Tidyverse style for function names is to use camel_case with the more general thing first: https://design.tidyverse.org/function-names.html [https://style.tidyverse.org/}(https://style.tidyverse.org/)
I think that means we should do the following, but eager for thoughts on this:
current
divMultBreaks
is a breaking function, so in harmony with e.g.scales::breaks_extended()
andscales::breaks_log()
, we should dobreaks_divMult()
. For this, I think using "divMult" as a camel-ized abbreviation is pretty good, even if this might offend some eyes? This is parallel with other usage e.g.label_divMult()
current
limBreaks
limits a vector of breaks, so maybe we wantlimit_breaks()
?for reasons I don't understand, in scales, the functions are
blah_trans
instead oftrans_blah
so although this seems internally inconsistent, I guess we should follow (i.e.nel_trans()
instead oftrans_nel()
in current package)I'll make the proposed changes in a branch.