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

Jeff Atwood made a nice blog post on refactoring and code smells, you might want to check that out.

Refactoring code in .NET takes some time to grok. You need to know some object-oriented design principles (or design techniques) in order to refactor effectively and mercilessly.

In short, you refactor code in order to remove code smells and make changes easier to do. Also, don't overdo it.

Answer 2

Check out Martin Fowler's comments and book on Refactoring

Answer 3

I'd recommend Domain Driven Design. I think both YAGNI and AlwaysRefactor principles are two simplistic. The age old question on the issue is do i refactor "if(someArgument == someValue)" into a function or leave it inline?

There is no yes or no answer. DDD advises to refactor it if the test represents a buisiness rule. The refactoring is not (only) about reuse but about making the intentions clear.

Answer 4

There's a web page dedicated to refactoring at http://www.refactoring.com/. It features many references to further resources on the topic of refactoring code as well as a mailing list to discuss refactoring-related issues.

Last but not least, there's a big (and still growing) catalog of refactorings available which extends well beyond what's written in the (very much recommended) Refactoring book by Martin Fowler.

Answer 5

Here is a review on slash dot of a book called Clean Code.

The book is apparently a little dry but very good.

Answer 6

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.