October 12, 2011

Code reuse, not a holy grail; not a guiding beacon.

Filed under: C# — Ian @ 9:54 pm

Over the years we’ve seen many idioms, patterns, methodologies and guiding principles come and go. I’d like the mantra of code reuse be one of the ones that go.

It’s one of those concepts much loved by “management” because of the perceived time savings. Build one reporting application and if it’s suitably flexible, everyone can use it! Wow!

The problem here is not in reuse per se, it’s in the re-purposing of existing code to cope with previously unanticipated requirements. It’s a mistaken belief that you are protecting the time already invested in a code base and saving time on future developments.

The reality is you end up with either spaghetti code, loaded with conditional functionality and little fixes introduced by those poor buggers that inherit the project.

That doesn’t always happen, sometimes it ends up as a hugely flexible framework driven by xml configuration files and its own unique scripting language. In effect it becomes an alternative programming environment. Your developer knows C#, now he has to learn the idioms of some meta programming solution.

So what’s the solution? Well, follow some of those nice easy to remember acronyms for a start. KISS (Keep It Simple Stupid) never hurts. YAGNI (You Ain’t Going to Need It) is great advice. SOLID (Ok, that’s five separate principles, google it) will keep you on track for software you can refactor.

But most of all, don’t fear the reaper. Code should be transient as it decays over time. Remember code consists of two things; the code itself and the knowledge of the developers using it. Developers come and go, so even the best code becomes half as clear once a new developer sits in front of it. Design your code with obsolesence in mind. Interface segregation (The I in SOLID) gives you the option of coding a new module against an existing interface to change functionality. Dependency injection (The D in SOLID) gives you the option of injecting that new module into the code easily.

Keep things small. If a class has a 1000 lines of code, chances are it doesn’t reflect the Single responsibility principle (S in SOLID (I am going through them all aren’t I…)).

Don’t use class access modifiers defensively. If you are making a lot of methods private, you will probably benefit from a separate helper class which encapsulates that functionality. Why? You can plug it in and out AND test it. Not private you see so you can run a few NUNIT tests against it.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

%d bloggers like this: