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. refactoring becomes hard (try finding all the places you have the duplicate code in)
  3. larger programs -> more code to maintain
  4. your application design is most likely 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 take 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 most fancy features. It’s about doing as little as possible to get the job done. I do not mean that you should take shortcuts or writing shit code. I’m talking about doing a simple solid solution which get’s the job done but nothing more.

Time estimation is still one of the hardest thing 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 do 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 when 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 UserReporsitory it should not do anything else than fetch/save you users from/to your data source. That’s what single responsibility means.

Why?! you ask. Well, letting your method/class/project doing 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 says 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. Imaging a cop mow a lawn.

Read more about single responsibility @ objectmentor || oodesign

That’s it

Again. Welcome to my blog. Leave a comment or two.