In a (sort of) response to some of the refactoring posts that Brandon Savage has been posting, Dagfinn Reiersol has suggested something that should have been done from the start - write unit tests before you refactor.

That said, I do have something important to add. The series is missing the first, most basic rule: Don't refactor unless you have good automated test coverage (typically with unit tests). And if there are no test, write them before you start refactoring.

He notes that with successful unit tests in place, you can freely change the underlying structure of the application with (almost) no worries that your application will fall apart the next time it's run. He does point out the need for a bit of refactoring before the tests could really be successfully run (since there's a need for an external twitter connection).

Brandon Savage has posted a few suggestions about dealing with coding standards and how they can help improve the quality of your code via his refactoring of a bit of example code. This time the focus is on documentation.

One of the first things I look for when I check out code is how is the code organized? Is it laid out well? Is it coded to a particular standard? In our code sample, the first thing we should address is how does the code look. There are a number of suggestions I would make immediately.

His list includes four suggestions for/comments about different areas of his example code:

• There are no DocBlocks or clear coding standards
• Examining The Properties (comments of the class properties)
• Conditionals (changing inline to braced)
• Improving The Constructor (to make it more flexible)