Do you rename code/modules with "old" names to their new names?

Question

Here's the scenario.

A long while back, the Powers That Be decided that a particular module should be called Widget Authorizations. As such, a whole lot of stuff was named after that:

• Database tables - AuthorizationTypes, AuthorizationFlows, etc.
• Database columns - Authorization_Id, Authorized_User, etc.
• Classes - AuthorizationBroker, IAuthorizable, etc.
• Files/Folders - \Admin\Authorizations\, CompleteAuthorizationForm.aspx, etc.
• UI Elements - labels, helper text, etc
• Printed Material - manual, brochers, etc.

Now, the same Powers That Be have decided that "Widget Authorizations" is a poor name and needs to be renamed to "Approval Sprokets" in the next release. So, my question is, how far do you go in renaming things beyond the Printed Material and UI Elements?

Is it worth the trouble/risk to change the code and back-end stuff? Will we really suffer that much if, to us, it's called WidgetAuthorizations but to the business/users it's ApprovalSprockets?

Answer 1

I don't rename code to "old". I just delete it. If ever I need it again, that's what version control is for.

There are two names for things in software:

• External names: these are on UI labels, in help text and so on. Basically if it's visible to the user, it's external;
• Internal names: these are not visible to the user and include things like database table names and column names as well as class and member names.

You change internal names as a result of code review because the given name is not clear or can be confused with something else. You also change them if a change in requirements means the purpose of the "thing" has changed such that the old name is no longer accurate.

You change external names because the business or other stakeholders simply want to.

Changing the external names does not mean you have to change the internal names.

So who are the "powers that be"? By all means change the wording in the application to suit the whims of whoever decides such things. Don't change your table or class names unless it makes sense.

Answer 2

I tend to think you should go all of the way, and keep the code self-documenting. There's nothing worse than seeing a comment like:

/* This is actually ApprovalSprocketID */
public void WidgetAuthorizationID;

(I'd send that one to thedailywtf!)

In order to do this, you may need some strong refactoring tools like Resharper. And you definitely need a SCC system that can REALLY store history, like Subversion. (If you're using VSS, refactorings like this can be DANGEROUS!)

This is also where a good unit test suite comes in. These tests take a lot of the risk out of these types of refactorings.

Answer 3

In a perfect world, the display names that you use on your UI and the files/folder names that your system uses and produces would be highly configurable. You shouldnt be reliant upon the whims of the PTB. Now might be a good time to reconsider the naming convention in your code to see if you can break from the strong coupling with the UI that you seem to have. If you are considering a large scale renaming excersise, now might be the time, for example, to name those DB columns ID and USER, foregoing the Authorized Sprokets malarky as much as possible.