I started reading the book Clean Code by Robert C. Martin and at the start I found this idea of his interesting, "Leave the code cleaner than you found it" adapted from the "Leave the campground cleaner than you found it". Now at my work in our code database I have this getter function in a class that gets a boolean value but is named
getConnectionActive instead of
isConnectionActive. I would like to rename it and leave the code a bit better.
A colleague that I asked about it pointed me to a rule of the company that conflicts. When we make git commits we are supposed to keep them as small as possible. This should make the commit easier understandable if somebody needs to read it and also, as far as possible keeps git blame pointing to the original author of some code. As an example they say that changing intendation is not good as it inflates the commit and changes git blame for all the lines. Intendation should be done right from the start.
So back to the method in question, if I change it in a commit that fixes another bug I would violate the companies rule as I would unnecessarily inflate the commit. However I cannot just make a commit of its own, as I always require a jira task number for a commit. So I would need to create a jira task only for changing this name. If done more often that would not only pollute the jira task history, it would still conflict with the companies rule of changing git blame, as it would no longer point to the commit that originally added this
getConnectionActive for some reason.
This situation reminds me of this comic strip. How would you suggest handling this? Is it worth to try and change the companies rules? Or is it better to leave the method name as is? Or maybe even rewrite the original git commit in order to leave as little trace in the history as possible?
(I hope this belongs in this stackexchange. I was also thinking about the code review stackexchange but I don't really have code to review. I was also thinking about the workplace stackexchange but my companies rule doesn't seem so arbitrary that this problem is restricted to just my workplace.)