Refactoring code

When I started doing my current job, I was well aware of the benefits of writing “good” code with clearly defined interfaces and small units of code (at any level such as translation units, classes or functions) that doesn’t repeat itself over and over again. But I sinned because of time constraints and general laziness.

I was enlightened when I read Clean Code by Robert C. “Uncle Bob” Martin. In this book, Martin explains reasons and detailed steps for refactoring code1. Don’t get me wrong, Martin is very dogmatic, the code examples too Java-centric and many observations are pretty obvious, but the book gave me the right amount of motivation to care more about the stuff that I produce.

Now, I was positively surprised when I stumbled upon [SourceMaking.com][], a compilation of software methods and tools published under CreativeCommons. Yes, it contains bits about UML and design patterns but the absolute highlight is the [refactoring][] section. Essentially, everything that’s written in Clean Code is presented in a logical and easily accessible way. For each refactoring method, a motivation is given why this method exists, mechanics how this applies to certain code structures and an example in Java.

But before diving into each refactoring method, make sure to read about the [bad code smells][] and reflect on that. I guess every one of us, is guilty of duplicated code and too long code sections.

1

Prior to this, whenever I heard the word refactoring I was immediately thinking about renaming classes and methods. Sure, renaming is important but not crucial to refactoring. [SourceMaking.com]: http://sourcemaking.com [refactoring]: http://sourcemaking.com/refactoring [bad code smells]: http://sourcemaking.com/refactoring/bad-smells-in-code