{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

Code Refactoring - Freaking Awesome

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:

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.

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

Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks