Databases

for RuBoard

Another area about which you should think carefully before refactoring is in production databases. When you refactor a database design, you incur the burden of porting data from the old design to the new one. This may be more trouble than it's worth, particularly if the database is already in production. Then again, you may find that it's an absolute necessity. It depends on the situation. If you're going to refactor a database, do so as early in the development process as possible. As with any type of software, the cost of changing a database on which applications are already based rises exponentially over time, the aspirations of Extreme Programming (XP) notwithstanding.

To Rename or Not to Rename?

Is renaming worth the effort? Some would say it isn't. That names for variables , functions, methods , and classes, once assigned and known by the code's owner, are insignificant in and of themselves . After all, they're symbolic names only, right? Renaming code elements to make them more sensible , so the thinking goes, is a simple case of compulsive behavior on the part of the programmer.

I disagree with this line of thinking. First, code should be self-documenting . It's been my experience that copious comments are usually a sign of poor coding or poor naming conventions in the code itself. They're often intended to obscure or justify bad code. Instead, I prefer meaningful names and minimal comments. Although I may know that Foo is the indexer for my for loop today, I may forget it tomorrow. It's far better to adopt a convention for such things so that I won't have to trust my fragile memory to keep from breaking the code, or waste time looking up poorly named code elements to figure out what they do. If a picture is worth a thousand words, a good name is worth at least a couple hundred.

Second, except when it comes at the expense of performance, improving the clarity of code is always a good thing, and renaming code elements with sensible names certainly improves the code's claritynot just for me, but for anyone who follows me in the code down the line. Renaming to improve clarity is just as valid a refactoring tool as Extract Method and Move Method [18] and is easily done via global find/replace editor commands.

I once heard an old programmer tell the tale of a fellow coder who attempted to ensure his job security by naming all the variables in his lengthy COBOL app using proper names from the Bible. (And you thought Foo was a bad loop indexer. Try Zechariah!) Although it may have protected his job for a time, I'll wager that it did little to endear his colleagues to him, and I'll bet the day came when he needed divine help to remember the names himself. Good names help everyoneyou and anyone else who ever works on your code.

[18] Fowler, Martin. Refactoring: Improving the Design of Existing Code . Reading, MA: Addison-Wesley, 1999. Page 15.

for RuBoard


The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
ISBN: 201700468
EAN: N/A
Year: 2005
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net