Refactoring Code: When to do what?

Question

Ever since I started using .NET, I\'ve just been creating Helper classes or Partial classes to keep code located and contained in their own little containers, etc.

Answer 1

My rule of thumb is to leave the code in no worse shape than you found it.

The idea is to work towards the better, without trying to achieve the perfect result, or go all the way.

Individual refactorings sometimes have a questionable benefit, and - as an extreme example - it might indeed be argued if m_Pi is a better name than m_PI. However, most often one choice is more consistent, and less surprising even if not obviously "better".

One situation where I regulary find myself refactoring automatically is before implementing a featureon a piece of code.

There are often a few TODO's waiting to be fed, some inconsistencies or sometimes custom functionality that has lately acquired better library support. Doing these changes before I implement the actual feature request gives me some understanding of the code, and I verify the "before" functionality.

Another point is after fixing bugs. After, so the before-repro isn't affected, and the bug fix and the refactoring are two separate commits.