If it is in a few well determined and localized places then I refactor the names. If it is a part of a major series of dependent changes, on multiple levels, multiple modules / subsystems, etc. then I leave it alone. For example, in our current system of many applications, several web sites, many middle and back end services we have an annoying misspelling which I'n not suggesting fixing because it basically touches everything. The same would happen on a domain terminology change.
And sometimes even more unfortunate naming happens. In my previous company we used the term 'category' for four completely different concepts. This led to much confusion and would severely complicate name changing.
I completely agree with this, if the scope is small and well-isolated, go ahead and make the change. For parts of your code that are large-spanning or change the public API (such as query parameter names or keys in JSON responses), leave them alone until they need to be changed.
And when you're renaming stuff, make sure to be very careful and very thorough with it. Small commits changing just a few files at a time is much better than one large one (you can always squash the commits in the end before merge). IDEs can sometimes get a bit too aggressive with renaming, so don't just "replace all", step through each and every match and verify that each match you do actually want renamed.
Definitely guilty of making enormous and aggressive "renamed X -> Y" commits. Didn't think about squashing smaller commits, even though I do that for feature branches all the time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If it is in a few well determined and localized places then I refactor the names. If it is a part of a major series of dependent changes, on multiple levels, multiple modules / subsystems, etc. then I leave it alone. For example, in our current system of many applications, several web sites, many middle and back end services we have an annoying misspelling which I'n not suggesting fixing because it basically touches everything. The same would happen on a domain terminology change.
And sometimes even more unfortunate naming happens. In my previous company we used the term 'category' for four completely different concepts. This led to much confusion and would severely complicate name changing.
I completely agree with this, if the scope is small and well-isolated, go ahead and make the change. For parts of your code that are large-spanning or change the public API (such as query parameter names or keys in JSON responses), leave them alone until they need to be changed.
And when you're renaming stuff, make sure to be very careful and very thorough with it. Small commits changing just a few files at a time is much better than one large one (you can always squash the commits in the end before merge). IDEs can sometimes get a bit too aggressive with renaming, so don't just "replace all", step through each and every match and verify that each match you do actually want renamed.
Definitely guilty of making enormous and aggressive "renamed
X->Y" commits. Didn't think about squashing smaller commits, even though I do that for feature branches all the time.