Code Refactoring - Freaking Awesome | mikebernat.com Web-Development, Design, Usability

Code Refactoring - Freaking Awesome

2009.01.02

We have all gone back and looked at code we wrote in the past and thought "Wow, this is ugly.", or "wtf was I thinking?", or even "I wrote this yesterday, and I have no idea what it does." Refactoring is the process of going back over already-working code and cleaning it up for the sole purpose of understandability, maintainability, and preserving your self-worth if anyone else were to take a peak. No one likes to be humiliated by their own code.

Refactoring is one of those ideas that has always floated around in my head but I never knew what to call it, or how to handle it. For me, it makes a huge difference to give a loose process like refactoring a name because it solidifies its usefulness. Sameer Borate wrote a nice introduction in a series of refactoring articles on his website. He describes refactoring as an idea similar to design patterns and unit-testing which, on the surface may seem to be a waste of time but in the end, saves a lot of frustration and grief.

Refactoring is a process of changing code to make it more understandable and structured without changing the code functionality or introducing additional bugs. Informally it is known as ‘cleaning up code’. Refactoring is based on the tenet that the written code is more important to the human reader than it is to the machine. Many programmers write code with the idea that once the program is complete and working the code will not be touched again. But this seldom happens. Features need to be added, bug issues need to be fixed. This may happen tomorrow or months from now; wherein you need to really remember what a particular function did. Comments in the code may be useful, but not much if the code written is not differentiable from the half eaten spaghetti bowl sitting beside.

In a nutshell, here is a snippet of an script that is completed and working:

<?php if (date('L', strtotime('+1 year'))) { // some code.. } ?>

I sure as hell can never seem to remember what some of the more obscure date format characters like capital L represent. If I were to look at this if statement I might have to take a few moments to look up what it's doing. L of course, returns 1 if i is a leap year, and 0 if not. You can quickly and easily make this code more readable by throwing that in a function and give it a descriptive name.

<?php if (nextYearIsLeap()) { // some code.. } ?>

This is a pretty crude example but I think it gets the point across. The big thing for me is to realize that you should not waste your time by trying to code in this fasion from the beginning. Rather, get the application working then go back and tidy things up. Just don't forget :p

Comments

Daniel Hofstetter on (1.3.2009 8:46 am) says

"[..] you should not waste your time by trying to code in this fasion from the beginning. Rather, get the application working then go back and tidy things up."

I disagree. I think it is rather an illusion that you will go back to tidy up your code after the application is working ;-)  Refactoring your code is a continuous process. If you see something in your code that could be improved, do it.

thud on (1.3.2009 10:08 am) says

I think what MB is saying is you should go ahead and code organically. Solving an application problem is a different mindset than writing clean, elegant code. If you focus too much on the latter, the former risks never getting done. And there always ways to improve non-trivial code.  So you can spend a lot of time polishing and never get to feature-complete.

Mike Bernat on (1.3.2009 6:33 pm) says

@Daniel Hofstetter

You always run that sort of risk :p

It's all about balance. For me, I find that I can take a 5 minute break to go back and tidy up some code I just wrote. After about 5 minutes, I have no trouble switching gears back and continue on the application. Some people are certainly different than me. Find what works best for you.

Tetsuo on (1.16.2009 6:37 pm) says

It will take you 5 minutes only if you coded that 5 minutes ago.

Mike on (1.16.2009 8:00 pm) says

@Tetsuo
I thought that was implied. 

If you do happen to refactor code, some form of testing is absolutely critical. Unit-testing is the best option.

Tetsuo on (1.17.2009 9:36 pm) says

Unit testing is good when refactoring, ok. But it shouldn't be an excuse for you to be sloppy and write unreadable code. In fact, unit testing is best used when you have functions/methods with good (readable) names, that represents its intent, not some 'yadayada()' method that for some reason should return 'true' when you pass '0'.