In an early example in Martin Fowler's book Refactoring: Improving the Design of Existing Code he highlights that renaming a variable or method is a legitimate form of refactoring. It can also be immensely helpful to the readability if the code. Here's an except from page 15 of the book:
Once I'm done renaming, I compile and test to ensure I haven't broken anything.
Is renaming worth the effort? Absolutely. Good code should communicate what it is doing clearly, and variable names are a key to clear code. Never be afraid to change the names of things to improve clarity. With good find and replace tools, it is usually not difficult. Strong typing and testing will highlight anything you miss. Remember,
"Any fool can write code a human can understand. Good programmer write code humans can understand."
Code that communicates its purpose is very important.
This is great advice from the main man of refactoring, Martin Fowler himself. From the examples in the book, it is clear that Fowler is a proponent of camel case variable and function names. He likes to keep it simple and descriptive. He models the software in terms is real objects, and the variables have to do with the world that software is creating. Also, don't be afraid to have long variable names if that's what the program needs. For, example:
int bonusAmountIfCurrentlyRaining;
is perfectly fine. However, if you do find yourself with unusually long variable names- to the point that it's just "getting in the way"- then you may need to do some more refactoring than just renaming variables.
RSS Feed