By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.
—- Joshua Kerievsky, Refactoring to Patterns

I had recently seen the above quote while sifting through some periodicals that I read and it reminded of the importance of Code Refactoring. Refacotring is a mindset that you must put yourself into. You have to decide that you do not write perfect code the first time and that there may be some room for improvement. An hour or two a day may be all you need to review your own code.

I recently spent two hours reviewing code from one of my modules that I had written. It had the same or similar code written in 5 sections in the code and had the same purpose to these sections. Each section had 11 or more lines of code in it. I took one of those sections of code and converted it to a function and then replaced the 5 sections with this new function. Ultimately I had eliminated 51 lines of code out of one module.

Reasons for Refactoring Code
1. Consolidating and eliminating “Like” or “Similar” Code
2. Breaking out a extraordinary long function into more manageable bites
3. Make error trapping easier to handle
4. Make code more readable and maintainable
5. Removing nested IF or logic Loops
6. Make it easier to document
7. Create Reusable code
8. Better class and function cohesion.

The benefits now are the following:
1. Similar code is now the same which is the way it was meant to be ( coded over three days, the code morphed a bit ).
2. Since the code had the same purpose, it looks the same now and behaves the same.
3. Code is in one spot instead of 5 – makes it easier for a base change
4. Error trapping is much more controlled.

If you cannot review your own code ( some people cannot and should not be ashamed for it ), you should get yourself someone you can trust to review the code for you. The do not have to modify the code, they can either insert comments to you, print out and scribble on the pages or meet with you. Never take it as bad thing if someone wants to change your code; take it as a learning experience. If you are using someone else, challenge them back. Make sure they know what they are talking about. A face to face meeting is always a good idea. A mentor, or team lead should be taking on the role of code reviewer. Code reviewer should be recommending ways to refactor your code. This should be done prior to release, deployment and ending a project. The review should always be done with the developer(s) responsible for writing the code. Should never be done without as that undermines the developer(s) and no one learns anything from it.