how to write code

This is going to be a very subjective post. I’ve been writing C# applications in .NET since the first release back in 2001 and I feel very comfortable with the language and the tool chain. I’ve certainly seen my fair share of ‘how not to write C# applications in .NET’. Although I am a C# programmer, this post is primarily about software engineering so it’s going to applicable to Java developers as much as it is to C# developers.

There are many critical aspects to software development, such as: knowing the API’s / frameworks that your code is calling (i.e. the .NET Framework), knowing your programming language intimately, knowing the runtime environment i.e. operating system / VM, having a reasonable application design, understanding the problem domain etc.

As important as these aspects are, they don’t play much of a part in the decisions concerning how to go about writing a software application per se – for example, how do I decide what classes will be in the application and how those classes will interact with one another? It’s difficult to answer these kinds of question as every scenario is different, but we can certainly define some useful rules to guide this creative process.

Shipping is without doubt the most important feature of software development. Without it, we may as well be monkey’s sitting at a keyboard trying to write the complete works of Shakespeare by pressing keys randomly for all the difference it would make to the world. Code that is badly thought out and badly constructed has a much lower chance of shipping on time, if at all.

Arguably the second most important goal of software engineering is to create a maintainable legacy. Don’t get me wrong, writing green field code is great…what’s not to like about it? But very few developers manage to avoid maintaining an existing code base during their career. In fact, the reality is that we probably spend most of our career maintaining a legacy as opposed to creating a brand new one from scratch. Therefore, creating a maintainable legacy should be one of the most important characteristics of any code we write. Next year, you could easily be maintaining my code or I could be maintaining yours.

So let’s kick off with a top ten list of essential software development rules:

  1. Every domain class should have a battery of tests for the behavior it is exhibiting (data only classes need no tests)
  2. Avoid inheritance unless there really is an *is a* relationship between derived and base
  3. Always practice interface based development with ‘Inversion Of Control’ provided by a container (i.e. Castle)
  4. Always follow the ‘Single Responsibility Principal’ when writing any domain class
  5. Refactor as soon as a class begins to sprout lots of private methods
  6. Always write clean (hygenic) code and that also applies equally to all unit tests \
  7. Domain classes, should always have an interface defined for them
  8. Domain classes should never new up other domain classes
  9. Avoid static classes as they defeat testing
  10. Only ever check in code that has been reviewed by a peer

Well, that’s the list for this blog post. I’ll be going into the details of each item in the next post, so stay tuned!


About aerlian

I am a software engineer
This entry was posted in C#, Uncategorized and tagged , . Bookmark the permalink.

One Response to how to write code

  1. jtreiner says:

    Very helpful. Even though I program in c++ I found this post extremely helpful.

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