Code

Writing Code

The other day I read this article and it got me thinking about how I’ve approached writing code over the years and how much technical debt is in that code. My hope is, as the years and experience have increased, the technical debt has gone down. I thought it might not be a bad idea to pass along some of what I’ve learned. Maybe it will help in your projects!

For this article, I’m going to concentrate only on the coding aspects of a project vs. customer requirements gathering and so on. I’ll save that for a future post.

First off, there is no single best way for writing an application. Like most things, it depends. However, I do believe there are a number of “rules” that can be applied to any coding project, no matter the language or platform. Some of these suggestions are mine and some I’ve picked up from other developers over the years. Here they are:

Rule 1 – Write easily maintainable code. If the application is going to be around for years, you will have to maintain it. This means comments, documentation and code that can be clearly understood and followed by others, or yourself, when you haven’t looked at a specific section for 10 years.

Rule 2 – The best code is the code you never write. Keep your code as short as possible. The less code you write, the less there is to maintain. This includes not using vendor generated code whenever possible as you can never be sure exactly what is in that code. Always ask yourself why is this code needed and is there a simpler way to implement it.

Rule 3 – Keep it simple. This ties closely with rule 2. Don’t add anything you don’t need. Always review your code and look for ways to simplify it and make it more concise. For example, jumping through 30 different functions to do a short process would qualify as something that can be simplified!

Rule 4 – Make generic functions for generic actions. Moving data in and out of a database is an example of a generic process. Write something short and simple that can handle any data that the application will use. This code can then be used in any application going forward. Most important, don’t turn that simple code into something that is difficult to use because it is wrapped up in multiple classes or is trying to be too generic.

Rule 5 – Be specific when being generic. Simply, don’t try to do too much in a single generic function. Keep the function true to itself. This ties back to rules 2 and 3.

Rule 6 – If you always do things the same, you are falling behind. Always learn, always explore, always try new things. Always do these things in test applications before implementing them in production applications!

Rule 7 – Design a framework or at a minimum, have a plan. It is a good idea to know where your application is “headed”. Will it be simple and never be modified, will it be complex with continual updates and new features or will it be something in-between? Knowing this will allow you to design a framework that will be better able to cope with the future and the present.

These rules are pretty broad and open-ended. That is by design as every project, every application is different. However, applying these principles will go a long way towards building a solid, easily maintained and modifiable product, that will be around for many years to come!