views:

189

answers:

9

Let’s say that you decide to change the name of Stack Overflow to Frack Overflow.

Now, in your code you already have dozens of objects and variables and selectors with some variation of the name "Stack". You want them to now be replaced with "Frack".

So my question is, would you opt to run your entire codebase through a regular expression filter and change all of these names? Or would you let them be?

Thanks.

+1  A: 

I'd first ask myself the question why? It is a risk/reward judgement at the end of the day which only you can make.

I would be very reluctant to do it for stylistic reasons, but for class re-factoring it may be legitimate.

Simon
+8  A: 

I would use the "rename" feature of a good IDE to do it for me.

staffan
+1  A: 

Well, not necessarily a disaster, but it certainly can cause some trouble on large code bases. That's why I hate hungarian notation: it makes you change all of your variable names if you happen to change its type.

Marc
+1  A: 

If there are objects, members and fields in your solution with names that reference a certain customer implementation, I would work hard to re-factor these to use more generic names instead, and I would let Resharper do the re-naming, not some generic text-search-and-replace tool.

Marcus
+1  A: 

Just use a refactoring tool like Resharper by JetBrains or CodeRush and Refactor! by DevExpress. They change all references of a variable in your entire codebase automatically and can do much more. I believe Refactor! is even included in the VB version of Visual Studio. I use Resharper and I refuse to develop without it.

Hermann
+2  A: 

It depends, really.

In a language like C++, you can get away with this because the compiler will let you know right away if something would break. However, other less-picky languages will allow you to refer to variables which don't exist, and the worst that happens is a slap on the wrist in the form of an exception being thrown for a null reference.

I was working on a flex project once where the codebase was a real mess, and we decided to go through the code and beautify it a bit to meet the Adobe AS3 coding standards. Since I was new to the project, I didn't realize that the variable names in some classes actually referred to persistent objects which hibernate (running the java webapp for the backend server) was using to create mappings. So renaming these variables caused the entire flex frontend to misbehave, even when we did it with the "correct" refactoring tools in our IDE.

But really, I'd say to check your OCD at the door and make your changes a little at a time. Any time you change dozens of files in a large project, you risk destabilizing it, and in this case, the benefit derived from such a risk doesn't pay off.

Nik Reiman
+1  A: 

If I were using a source code version control system (like svn, git, bazar, mercurial etc) I would not be afraid to refactor my code.

Use some kind of "find replace all" or refactoring of some IDE, compile (if it is not a dynamic language) and run your tests (if any).

If something goes horribly wrong, you can always revert your code using the source control system.

Kjetil Watnedal
+1  A: 

Renaming is perhaps the most common refactoring. It is rather encouraged to refactor your code as you go, as this gives you the flexibility of not having to make permanent decisions about names, code placement, etc. as you are first writing your application. If you are not familiar with the idea, I would suggest you start with the Wikipedia page and then dive into Martin Fowler's site.

However, if you need to write your own regex to rename things, then imho you could use some better tools. Don't waste your time reinventing the wheel -- and then fixing whatever your new wheel broke by accident. If you have the option, use an existing tool (IDE or whatever) to do the dirty work.

Even if you have "dozens" of things to rename, I think you're better off finding them one by one manually, and then using an automatic Rename to fix all instances throughout your code.

Tiberiu Ana
A: 

You need good justification for doing it, I think. When I make changes that have a large number of potential side effects across a large codebase, which happens from time to time, I usually look for a way to make the compiler fail on spots I've missed. And, if possible, I tend to do it in stages so as to minimize the break.

I wouldn't rename just for the sake of renaming, though.

Dan Olson