Smarter axis label -- allow string manipulate function in labs or theme

[albert-ying]

The current default behavior of ggplot2 is to use the column name as the axis label. This is usually bad as we tend to use lower-case character and '_' in the column name.

Example

library(tidyverse)
tb = iris |>
  janitor::clean_names() |>
  as_tibble()

tb

# A tibble: 150 × 5
   sepal_length sepal_width petal_length petal_width species
          <dbl>       <dbl>        <dbl>       <dbl> <fct>
 1          5.1         3.5          1.4         0.2 setosa
 2          4.9         3            1.4         0.2 setosa
 3          4.7         3.2          1.3         0.2 setosa
 4          4.6         3.1          1.5         0.2 setosa
 5          5           3.6          1.4         0.2 setosa
 6          5.4         3.9          1.7         0.4 setosa
 7          4.6         3.4          1.4         0.3 setosa
 8          5           3.4          1.5         0.2 setosa
 9          4.4         2.9          1.4         0.2 setosa
10          4.9         3.1          1.5         0.1 setosa
# … with 140 more rows

Default plot

p = tb |>
  ggplot(aes(sepal_length, sepal_width)) +
  geom_point() +
  theme_bw()

p

With better labeling

smart_label = function(lab) {
  str_replace(lab, "_", " ") |> str_to_title()
}

p$labels = p$labels |>
  map(smart_label)

p

The second one looks more "normal". And even if it shouldn't be the default behavior, there should be an easy argument in theme or labs to toggle this behavior. Or allow user to supply the function to manipulate the labels.

[clauswilke]

I guess the request here is to make the name argument in scales accept a function as input, just like the labels argument does.

[thomasp85]

@clauswilke I think that makes sense - we are not going to change the default behaviour...

@albert-ying are you up for making a PR?

[teunbrand]

I guess the request here is to make the name argument in scales accept a function as input, just like the labels argument does.

Just wanted to mention that, if this is the case, #4313 seems related. There are proposed changes in the issue that appear to work.

[thomasp85]

#4631 is also related to this

[hadley]

Closing as duplicate of #4313