You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is similar to #563, but a more generalized problem.
I often want to receive data that does not have clean names (well, I don't want to, but I do receive it 😄 ). I then run it through clean_names() for a first pass at cleaning it up, and I subsequently rename again to the final column name that I want to use for my analysis.
When I report data issues back to the person who supplied the data to me, I would prefer to be able to tell them the name from the original data. This is generally similar to what is in #563, but the difference is the generalization not just to use clean_names() but to allow it for any type of renaming.
For variations to consider, how does it behave for the first vs. after the first call:
data|>
rename_store(B=a) |>
rename_store(C=B)
After the first step, "a" is stored.
After the second step, what is stored? Options that I think are useful are:
Keep the original name ("a")
Keep the most recent name ("B")
Keep the full history (c("a", "B")). This would be harder to work with as it's not as simple as the label attribute.
We could also let the user choose among the choices above.
@jospueyo and @sfirke, any thoughts on the usefulness and implementation of this?
The text was updated successfully, but these errors were encountered:
I never change the names after the clean_names(), but I understand this can be useful as a more general workflow than #563.
Would you save the old names as attributes? As you said in #563, this is easily lost and should be properly documented.
I would save the full story, restoring the originals could be the default behaviour, but other names could be restored using an index. Even a negative index such in git log.
This is similar to #563, but a more generalized problem.
I often want to receive data that does not have clean names (well, I don't want to, but I do receive it 😄 ). I then run it through
clean_names()
for a first pass at cleaning it up, and I subsequently rename again to the final column name that I want to use for my analysis.When I report data issues back to the person who supplied the data to me, I would prefer to be able to tell them the name from the original data. This is generally similar to what is in #563, but the difference is the generalization not just to use
clean_names()
but to allow it for any type of renaming.For variations to consider, how does it behave for the first vs. after the first call:
After the first step, "a" is stored.
After the second step, what is stored? Options that I think are useful are:
c("a", "B")
). This would be harder to work with as it's not as simple as thelabel
attribute.We could also let the user choose among the choices above.
@jospueyo and @sfirke, any thoughts on the usefulness and implementation of this?
The text was updated successfully, but these errors were encountered: