Over the years of programming, I have gone from a simple spaghetti developer to an object oriented, method mineralized, property loving, defensive coding and structure focused (spaghetti) developer. So what is the difference? When I think about it, my code may look like a spaghetti program today, for the untrained eye that is, because of object inheritance, events, properties and so forth. But it's much better organized than it was just 20 years ago. The big advantage is that it is much easier to spot and avoid errors than in the good old spaghetti programming days. But I still need to avoid programmatic and logic errors, therefore I follow these 10 basic commandments in writing code.
- Assumptions are the mother of all errors.
- The most lacy developer do things right the first time.
- If something can go wrong, then it will at some point do.
- Never implement bad exception handling. Like the Ostrich-algorithm, where you put your head in the ground and pretend that nothing has happened.
- Know your events or you program will fail.
- Errors usually appears where you least expect them to.
- Users come from the dark side and they got errors with them.
- Unit test... unit what?
- Keep it simple! However this does not apply for the female developers, they are able to multi task!
- Always include a dead-man switch in a While loop, if it potentially can loop forever.
You will find some of the commandments more relevant than others but they all still holds an important message.
Defensive programming (link)
When using a defensive programming strategy and following the commandments I tend to think what can go wrong in my code and how to prevent it from doing so or simply handling it. This turns into rock solid applications that help me sleep better at night. The effort required is actually less than that of the ordinary "spaghetti code", because you don't spend the time constantly debugging your code in the end when the users keeps coming back with new errors that they have found.
Three strikes and you're program is out.
In the beginning when a user first starts to use a program, they have the stomach for three errors before they tend to give up on it and look for another solution. Therefore it's very important that the users are not presented with the errors directly in the face every time something goes wrong. Fallback gracefully when an error occurs is very important so the users don't feel abandoned.
Detailed description of the commandments.
- Assumptions are the mother of all errors.
Picked up from the movie Under Siege 2: Dark Territory (1995), where one of the bad henchmen (Penn) believes that he has killed Casey Ryback (played by Steven Seagal), but it's just an assumption and therefore Ryback is able to continue haunting the bad guys and finally finishing them off (think of yourself as one of the bad guys :-) The same thing applies to code - when you assume something will work, it will for sure come back to haunt you. (Nobody wants a Ryback running around and destroying their program). Every error in a program is there because the developer assumed that it was fine there was no possible scenario for an error. Don't make assumptions – know for sure and handle any possible outcome!
- The most lacy developer do things right the first time.
If you want to save time and errors when creating a program, do things right the first time. Otherwise you just end up forgetting that you have skipped a step here, cut a corner there, so on and so forth. Yet again resulting in an error when you least except it.
- If something can go wrong, it will at some point do.
This is a universal rule (another variant). Don't try ignoring it. The only thing is to make sure that nothing can go wrong. However even the best developers cannot avoid all errors therefore contain the error so it will not affect the outside world and implement a graceful fallback error handling routine.
- Never implement bad exception handling. Like the Ostrich-algorithm, where you put your head in the ground and pretend that nothing has happened.
This is a common error handling that I have seen in various places, where the developer knows that something can go wrong, but is too lazy to implement a descent error handling logic. Thereby resulting in a possible unstable program. This happened to me once when another developer in my team made an empty try catch statement around a database call. When the call to the database failed - and it did happen from time to time - the code simply just continued like nothing had happened, resulting in that the database data became invalid. So I had to spend 2 full days debugging the entire code in order to find out why the program was unstable and not knowing where the error prune part was hiding.
- Know your events or you program will fail.
This is one of the most important things you can do when coding in object oriented languages. Know in what order things happen in. I have seen a lot of developers writing a lot of bad code in ASP.NET because they simply haven't allowed themselves the time to study how a Page lifecycle works.
- Errors usually appears where you least expect them to.
This is another law of the Universe. You might as well accept it!
If you ever think a certain situation will never occur, you are properly wrong. I have heard this so many times "This will never happen… yada yada yada" – but trust me, it will! So always implement at least a minimal form of error handling.
- Users come from the dark side and they got errors with them.
No developer can foresee every possible outcome of a program and users have the tendency to pick out the situations that you had never have thought of. So always think of in general error handling, so you can say to yourself… "Whatever happens, I have covered it."
- Unit test... unit what?
This is an important thing to remember, especially when doing a lot of backend logic. There has been written a lot of topics on this subject and therefore I will not cover it here.
- Keep it simple! However this does not apply for the female developers, they are able to multi task!
Male developers tend to develop programs with their forehead. This puts a constraint on how many of lines of code that they can handle simultaneously. Males like giant things, but giant methods are a bad thing. It is easy to lose overview of what is going on in the method with too many lines of code and therefore the possibility for errors sneaking in is greater. Keep your methods at a minimum, even if they are just used once in a call from one other method.
- Always include a dead-man switch in a While loop, if it potentially can loop forever.
All developers in world has made this one at least once in their lifetime. Creating a While statement but forgets that they can potentially run forever and it stalls the process. So if there is even the slightest chance that a While statement can loop beyond its intention, introduce a dead-man switch. A simple counter that can only count to a certain amount before ending the while loop.
This more or less concludes my 10 commandments. Read it, learn from it and hopefully improve on it.
