From future Lara: I wrote this post a few months ago and came across it today as I cleaned out my post drafts. I am now future Lara, and this is sound advice, but keep in mind that as with any advice, it depends on the context.
July, 21, 2020:
In my conference talks, I quoted Robert C. Martin along the lines of:
Naming is hard, and very important. Choose the best names you can, and change them when you find better ones.
Me, paraphrasing Robert C. Martin in Clean Code
HOWEVER.
Probably don’t do this when the name in question is the name of a directory that is referenced by multiple other code-bases. Why? Because in two months or less, when you look at the code-base and dislike the new name and want to change it back to the original name, it is much harder to do. And don’t hard code paths anywhere.
This seems obvious in hindsight, but at the time, I was like, “Nice, this is an opportunity to rename this thing and it feels so much better and cleaner with this new name.” And now I think the new name is a crappy name and I want to change it back. What will I do?
Next time, I will strongly question renaming something just because it feels better to me.
Additional thought from future Lara: I think this applies to name changes that are high impact, like a directory that has a path coded in other places. There are good reasons for high impact name changes. If the new name “feels better” because it conforms better to an established standard, and the code-base is in active development, then that could be a good reason to change it. If, as in the above example, it “feels better” due to personal opinion in the moment, or you want to update an old code-base to standards “just because”, then think twice about changing the name.