Refactoring -- refactored

It looks like "refactoring" is indeed a four letter word for some of you, while others seem to have no problem with it. Perhaps what I need to do is define a little more closely what I mean by refactoring or, to be more precise, what I didn't mean.

1. If you are not actively involved in making a change to a particular method or function, you do not refactor it. "If it ain't broke don't fix it", in this case, is true. When you open up a program your purpose is to implement specific functionality. Modifying code that is related to delivering that functionality is part of refactoring. If you see another method that needs to be refactored, put in some comments so that the next person knows what to do, but unless it is involved in what you are doing, don't refactor it.
   
2. If your refactoring is going to end up changing interface contracts with other code, you are no longer refactoring, you are redesigning. At this point put down the mouse and tell the Project Manager. If you need to change the interface contract to deliver some specific functionality (see item #1 above) then there may be more problems and it should be looked at in closer detail.
   
3. If you refactor code, you retest code. Now, since you are only refactoring code that you are changing to implement specific functionality (see item #1 above) that shouldn't be a problem. This code should be approached as if it is fresh, newly written code, and if it has been refactored it very well may be, so a complete test is going to be required. (Automated Unit testing anyone?)
   
4. If you aren't sure if it is going to make the code better, don't refactor it. If you aren't sure if it is going to make things more maintainable, don't refactor it. If you aren't sure what constitutes better code or more maintainable code, don't refactor it.
   
5. If your only purpose is to make it look prettier, don't refactor it.
   

Refactoring is meant to improve things, but it should also be limited to what you are working on, not unrelated areas of the application. These boundaries are put in place so that people don't spend all of their time refactoring code and none of it adding new functionality.