Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better names for functions ending in _custom() #11

Open
teunbrand opened this issue Apr 27, 2024 · 6 comments
Open

Better names for functions ending in _custom() #11

teunbrand opened this issue Apr 27, 2024 · 6 comments
Labels
help wanted Extra attention is needed

Comments

@teunbrand
Copy link
Owner

teunbrand commented Apr 27, 2024

I'm discontent with the name of some function that end in the _custom() suffix.
Famously, naming things is one of the harder things to do in programming.
I'd gladly entertain alternative names for these.

Currently, it concerns the following functions:

  • guide_axis_custom()
  • guide_colourbar_custom()
  • guide_coloursteps_custom()
@teunbrand teunbrand added the help wanted Extra attention is needed label Apr 27, 2024
@davidhodge931
Copy link

An idea is to use guidance_* instead of guide_* for all of your guides. E.g. guidance_colourbar()

I presume all of your guides will act in a similar way with args etc. So then I think it's useful to the user for it to be obvious as to whether the guide is from gguidance or ggplot2.

Also, I think "guid" with autocomplete would give all ggplot2 and gguidance guides, and "guida" would give just gguidance guides. That'd be nice!

Don't know your r package well enough to know if this would be internally consistent with how everything else is named though..

Another idea you've prob throught of is to use 2 instead of custom in the name.

Good luck! Naming is hard

@teunbrand
Copy link
Owner Author

I like the idea of using a guidance_ prefix, but the 'guide from string' method of declaring guides, e.g. guides(x = "axis", colour = "colourbar"), requires the functions to have the guide_ prefix. Using 2 as a suffix was what I used in earlier iterations of this package and the reason I didn't stick with it was it nondescript-ness.

@davidhodge931
Copy link

davidhodge931 commented Apr 28, 2024

Ah damn, didn't think of that...

Only other idea is a play on words. But would need to be misspelt unfortunately..
guide_ance_axis()
guide_ance_colourbar()
guide_ance_coloursteps()
guide_ance_colour_ring()

guides(x = "ance_axis", colour = "ance_colourbar")

Not sure whether this is good or not. The strings look a little weird. But it's another idea anyway

@davidhodge931
Copy link

Maybe the above is too weird.

If you use a word in your guide names like 'custom', I think you should consider applying it to all of your guides - given that they will all operate with this custom-ness/flexibility - and this would identify them as being from your package.

Other ideas for this word are flexible, flex, flexi, ply, plyr or plie..

@aphalo
Copy link

aphalo commented Apr 28, 2024

@davidhodge931

Only other idea is a play on words. But would need to be misspelt unfortunately..

What about adding a "d":

guide_dance_axis()
guide_dance_colourbar()
guide_dance_coloursteps()
guide_dance_colour_ring()

guides(x = "dance_axis", colour = "dance_colourbar")

Probably too crazy and too long, but easy to remember.

@teunbrand
Copy link
Owner Author

I like the dance infix, but I'm not sure I'd want to mark all functions that way. I also like _flex() as a suffix. I'll let this percolate for a while, thanks for the suggestions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants