For all the hackers out there..

Posted by: stak
Posted on: 2007-04-18 22:18:16

.. some advice worth following.

This brings back a pet peeve of mine when it comes to code cleanliness: people are always afraid to refactor. Refactoring and cleaning code is one of the best things you can do to improve overall readability and maintainability of code, yet so many people prefer to go with the "Don't fix it if it ain't broke" philosophy and just hack around things that may not be optimal.

The thing about code is that most of the time, when it's written, the programmer doesn't know how exactly the code is going to be used. Sure, in a perfect world, we'd have requirements and specifications that would be set in stone and would dictate exactly what the code needs to do, but the world isn't perfect. In 100.000000000% (rounded to 12 significant figures) of cases, code will evolve and change. And the person who writes the code will not be the one who has to change it.

What this means is that more often than not, when you come across some code that doesn't do something in a "clean" way, it's because the person who wrote the code didn't know how you would be using it. Do everybody a favor and fix it properly, rather than just working around it with ugly hacks.

That being said, there are obviously precautions to be taken before refactoring existing code willy-nilly (aside: I seem to be using this phrase a lot more recently). You should make sure that your proposed changes are, in fact, a valid use or extension of the original code. Just because the code does something similar to what you want to do doesn't necessarily mean you should use it; the semantic meaning of what the code does should fit what you're trying to do. Also, if there is other code that depends on the code you're modifying, try to refactor the entire chunk together, rather than hacking up the other depedent code to work around your new refactoring. This may require talking to other people who own the relevant pieces of the code and coordinating changes so that stuff doesn't break.

I've often thought it would be a really cool job to just be "the refactoring guy" for a product at a software company - not assigned to any particular feature/project, but with carte blanche to refactor anybody's code to make it fit better into a cohesive whole. The developer would also be responsible for pulling out libraries across products and code reuse in general. Unfortunately, it would be extremely difficult to set goals or measure the effectiveness of such a role. I think most companies don't have one of these positions explicitly because it's hard to justify paying money to a developer who, strictly speaking, doesn't have to do anything. Instead, one or more developers usually have to step up and take on this role in addition to their usual tasks - and all they get for their trouble is a yelling for meddling in other people's code.

[ Add a new comment ]