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.
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.