The blog post I chose comes from a widely known programming blog, The Clean Code Blog. The Clean Code Blog is written by Robert C. Martin (Uncle Bob). The post we will be discussing today was posted on January 20, 2012, and is called “Fecophiles”. The post focuses on two subjects: refactoring and code smell. It talks about a section of code that was refactored by someone and, oddly enough, received negative feedback from some of his coworkers. To clarify the rest of the post, Uncle Bob refers to “Fecophiles” as people who like to “smell” code. Amidst many harsh, and perhaps aggressive, comments about the coworkers’ reactions, Uncle Bob goes through 13 points proving that the original code under analysis “smells.” Screenshots of the initial code and Uncle Bob’s refactored solution can be found on The Clean Code Blog.
This post caught my attention for a couple of reasons, including how refactoring is helpful and how it addresses code smells. Refactoring is a technique that demonstrates how coding in teams or practicing peer coding is a good practice. Often, the way I see a problem and the solutions I come up with could be completely different from someone else’s. Not only that, but refactoring may also improve runtime, thereby increasing the code’s efficiency. There is always the possibility of a better way to solve a certain problem. A new solution might involve using different or more efficient techniques. A statement I always remind myself of is: “Two heads are better than one.”
On the topic of code smells, I will point out a couple of issues the code in question had. The code exhibited needless complexity and unnecessary repetition. The original code, before refactoring, checked the same condition two or three extra times. Because it repeated the same thing too many times, it became more complex than necessary.
But is such code really that problematic? I don’t think so. I could call it a different way of reaching the same point. Sometimes, the original code was simply an expression of the solution as the developer initially conceived it. The biggest issue is that it should not have been left that way. After writing down the solution to a problem, it may become easier to visualize a different, better approach. This is something I will apply to myself in the future—writing down the solution or coding it, but always reviewing it with the intent of making it cleaner and more functional.
From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.