Wednesday, June 30, 2010

ALM Practices Part 7: Refactoring

What is it?

A mindset and practice that requires you to continuously reevaluate a region of code each time you make a change. In essence, you need to look at the code related to your changes and reconsider whether the original solution is still the best solution accounting for the information you currently have (and did not have at that time). Refactoring is a core practice of the Test Driven Development.

Why would you do it?

  • Because, unfortunately, experience has proven that is virtually impossible to design a foundation or architecture that we never have to chance anymore. So in reality and in most situations, software is created incrementally by adding new bits and pieces on top of each other without reconsidering its foundations.
  • Because any technical solution, both on an architectural level or at code level, is based on the knowledge you have at that point. Practice has proven that this knowledge improves over time and often becomes more focused, but is difficult to predict beforehand.
  • Because of advancing insight it is possible that certain domain concepts (such as those part of the Ubiquitous Language) have been refined or renamed, and you want to make sure your code reflects those changes that all time.
  • Because if you apply refactoring rigorously, you can start a project with Little Design Up Front instead of the infamous Big Design Up Front (can you predict the future?). Refactoring keeps your code base in good shape, so it’ll be easier to adapt your system or product to new requirements or technical changes.

What’s the bare minimum you need to do?

  • Replacing obscure or complex code with more simpler code that complies with common design principles and design guidelines.

What’s the usual thing to do?

  • Rewrite redundant and/or similar code so that you never have to apply the same change to multiple blocks of code, or, in other words, be DRY (Don’t Repeat Yourself).
  • Remove unnecessary or unused code (including commented-out code).
  • Considering the Single Responsibility Principle, move code that is at the wrong place in the code base.
  • Remove unnecessary dependencies between unrelated classes.
  • Rewrite code to comply with your coding guidelines and coding layout rules.

How do you do that?

  • Apply Test Driven Development because it promotes choosing the simplest working solution possible and includes refactoring as one of its basic steps.
  • Uphold to The Boy Scout Rule. Always, and with that I mean always, make sure that each and every source control check-in leaves your code base in a better shape than it was before.
  • Keep the A4 cheat sheet of the Coding Guidelines for C# 3.0 and C# 4.0 close to continuously remember yourself of its most important guidelines.
  • During a review, not only check that a block of code is functionally correct and uses the right layout, but also try using a high-level view to see whether that block of code is still at the right spot, or needs refactoring.
  • Check that the name of a type or member is still covering its purpose.
  • Print out the ReSharper Keymap and learn yourself the keyboard shortcuts for its many refactoring features.
  • Make sure you use ReSharper’s Visual Studio Keyboard Scheme so that other developers will not run into issues when you are pair programming with them.
  • Also include your automated unit tests when refactoring your code. Unit tests are first class citizens in your code base, and must of top-notch quality at all time.
  • Use the complexity of your unit tests as a measure of quality. If they are difficult to understand or anything other than small, changes are that the tested class (or subject-under-test) is either too complex or has too many responsibilities.
  • Consider using Clone Detective for Visual Studio to analyze your code base for duplication. It’s a free add-on for Visual Studio that will detect similarities in code constructs and can give you a quick analysis of your duplication.
  • Consider using the Wall of Pain principle to keep track of your major architectural or technical issues and have a controlled and transparent way for fixing those.
  • Seriously consider reading Robert C. Martin’s (a.k.a. Uncle Bob) Clean Code and Steve McConnell’s’ Code Complete. Both books provide very valuable guidance and background information on how to create high quality software.

Monday, June 28, 2010

Coding Guidelines for C# 3.0 and C# 4.0 now available

As promised earlier, you can now download the concept version of my new Coding Guidelines for C# 3.0 and C# 4.0 from a dedicated CodePlex site at The list of changes is quite big, and includes new guidelines covering object-oriented design, design principles, C# 4.0 and the smells and heuristics from Robert C. Martin’s book Clean Code. I’ve also removed many guidelines that have become obsolete or deal with situations that rarely occur. And the entire document has become much easier to read because I’ve changed to a less formal writing style.

A common question I receive regularly is how to introduce coding guidelines or coding standards into a team or organization, so I’ve adapted my April post on Coding Guidelines and included it into the document. Another question I get asked commonly is what to do if something is not covered by the document. For this, I’ve included my most favorite design principles that should help you determine when something is valid or not.

Similarly to the quick reference guide for the C# 3.0 version of the document, I’ve included a two-page A4-sized cheat sheet with the most important guidelines and some handy tables on naming, ordering and layout.

And finally, Jonne Kats and I started creating a set of FxCop and StyleCop rules that verify your code against some of the guidelines in this document. It’s a side project, so it may take a while before a first release will be made available. In the mean time, check out the source code repository regularly.

And last but not least, this document has not been cut in stone. So if you have remarks, comments, additions or complaints, just let me know. I’ve already received valuable feedback from the community and will continue to update the document whenever something useful comes to my attention.