Re-rename change_code()?

[IndrajeetPatil]

Before we finalize this, we should definitely decide on the new function names. Mostly, I'm not quite satisfied with change_code(). recode is a verb, and everyone would expect such a function would recode old into new values. in change_code(), the verb is change, and what can we expect if we change a code? What we actually change when recoding are values (or factor levels, but values is maybe more generic). What do you think about change_values()? or maybe recode_values(), or recode_variables().

Originally posted by @strengejacke in #87 (comment)

[IndrajeetPatil]

The "code" being the mapping of quantities to values/labels. So the function is changing the coding scheme used.

Maybe change_coding()? change_values() would be my second choice

Originally posted by @bwiernik in #87 (comment)

[bwiernik]

I like change_coding() or recode_values()

[DominiqueMakowski]

recode_values() +1

[IndrajeetPatil]

@strengejacke I don't think this is low priority.

We need to finish renaming in as few release cycles as possible. We can't keep changing function names every time we update the package; it doesn't reflect well on us.

I would like to be done with renaming for the existing functions in the next (0.6) release.

[strengejacke]

ok, than let's go for recode_values().

[bwiernik]

In the future, if there are lingering concerns about renaming a function or argument, I'd like to not merge or at least not release until there is consensus. Eg, we probably should have left data_recode() in place until we settled on an alternative everyone was happy with