jgauffin's coding den

Thoughts and ideas about architecture and programming

· Jonas Gauffin

DRY KISS, SR!

omg! wtf?! Nahh, this ain’t a porn blog. The title is three coding principles that I try to follow when I code. And this blog is going to be all about them.

You’ll find code refactorings, insights and such that I discover during my days as a software architect/developer.

As you might notice, no entries will be elaborate or poetic. They will be short and concise: HARDCORE!

DRY – Don’t repeat yourself

Most of you have probably heard of this principle. You can read more about it at Wikipedia.

Code duplication is evil since you:

  1. can get the same bug in a lot of different places
  2. make refactoring hard (try finding all the places where you have the duplicate code)
  3. get larger programs -> more code to maintain
  4. have an application design that is most likely as bad as a rotten apple

Let’s focus on the last entry. Sorry, but it’s true. If you need to duplicate code, you have done something wrong. Go and grab a coffee. Go through your code and try to refactor it. Ask a colleague of yours. DO NOT CONTINUE UNTIL YOU SOLVE THE PROBLEM. Trust me. You’ll regret it later.

KISS – Keep it simple (and) stupid

I have a really active brain. It comes up with all sorts of cool stuff and solutions when programming. That’s a BIG problem when coding. Coding is not about having the coolest solution or the fanciest features. It’s about doing as little as possible to get the job done. I do not mean that you should take shortcuts or write shit code. I’m talking about a simple, solid solution which gets the job done but nothing more.

Time estimation is still one of the hardest things to do when developing software. How long have we been coding? 40 years? And we still can’t do proper time estimations. El oh el! Do you know why? Because most programmers do not keep it simple! We love to learn new stuff and build cool solutions.

Finish the application first! Then do the fancy stuff.

Read more about KISS at Wikipedia.

SR – Single responsibility

Have you ever seen a cop (Mr. Police) mow a lawn while on active duty? (If you have, please give him this link.) I thought not. Why? Because doing a lot of different things would make him a bad cop. It’s the same with your classes, methods and projects. Don’t let a class both fetch the users from the database and present the info to the user. Do not let a method both send an email and eject the CD tray.

If a class is called UserRepository it should not do anything other than fetch/save your users from/to your data source. That’s what single responsibility means.

Why?! you ask. Well, letting your method/class/project do a lot of stuff will make it hard to understand what your application does. It will also make it harder to understand. But the most important thing is: it will make it hard to test your application (unit tests). And you don’t want that. Unit tests are a life saver when your application grows. All those green dots that say that the tests have passed will give you a warm fuzzy feeling inside when your application is 5M lines long. Imagine how hard it would be to test an app that large when all your classes do a lot of different stuff. Imagine a cop mowing a lawn.

Read more about single responsibility @ objectmentor || oodesign

That’s it

Again, welcome to my blog. Leave a comment or two.