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.

What I'm looking to know is the best practices for making ones code as clean and polished as it possibly could be.

Obviously clean code is subjective, but I'm talking about when to use things (not how to use them) such as polymorphism, inheritance, interfaces, classes and how to design classes more appropriately (to make them more useful, not just say 'DatabaseHelper', as some considered this bad practice in the code smells wiki).

Are there any resources out there that could possibly help with this kind of decision making?

Bare in mind that I haven't even started a CS or software engineering course, and that a teaching resource is fairly limited in real-life.

Answer 1

A real eye-opener to me was Refactoring: Improving the Design of Existing Code:

With proper training a skilled system designer can take a bad design and rework it into well-designed, robust code. In this book, Martin Fowler shows you where opportunities for refactoring typically can be found, and how to go about reworking a bad design into a good one.

Refactoring http://ecx.images-amazon.com/images/I/519XT0DER6L._SL160_PIlitb-dp-arrow,TopRight,21,-23_SH30_OU01_AA115_.jpg

It helped me to efficiently and systematically refactor code. Also it helped me a lot in discussions with other developers, when their holy code has to be changed ...

Answer 2

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.

Answer 3

Check out Martin Fowler's comments and book on Refactoring

Answer 4

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 5

• Re-factor you code when it is causing problems. Any problems will do: performance, scallabillity, integration, maintainance - anything which makes you spend more time on it when you should. It it is not broken do not fix it even if you do not believe it is clean or is up to the modern standards.
• Don't spend too much time making the code perfect. You will never achieve perfection but you could spend lots of time trying to do so. Remember the law of diminishing returns.
• Inside a project only re-factor the code when you are actually working on the functionality which depends on it. I.e. if you have a user story for the iteration calls for a "change the upload mechanism" or "fixing the bug in the file upload" you could re-factor the file uploading code. However if your user story is about "facelifting the file upload UI design" do not go into the business logic.

Answer 6

I just got a copy of Code Complete, and found that there was a section on this.

Although I will still be reading the accepted answer's book, what Code Complete has taught me has dramatically improved the way I think about designing classes.

Before today, I didn't know what an ADT was (abstract data type), and now I know how to develop classes adhering to the encapsulation.