I apologize that it’s been a while since I last wrote something here. The lack of content was due to the fact that I have been reassigned to a non .net project for the foreseeable future.
I do, however, want to share with you a school of thought I developed during my many months of creating infrastructure code and forming coding methodologies in my last project. Maybe someone has already thought of it before. If they have, let me know. :)
I like to call this school The Zero Trust Rule or Zero Trust for short .This would mean that while you enable a programmer to work over your program or code, you will do so under two guidelines:
- Never trust programmers to not make mistakes. About anything.
- Help programmers understand the err of their ways when they make their mistakes.
For an example of the first rule, let’s take a simple scenario: MyClass exposes a property of type Object, but can only receive instances of type SomeClass. If the property receives a different type, it throws an exception.
This doesn’t coincide with the first rule. The first rule clearly states that you should never trust any programmer (even yourself) to not make mistakes.
So we change the property to receive only objects of type SomeClass. This way, the programmer can not make a mistake of setting it to a different type.
A great example of the second rule would be the ObsoleteAttribute. In this case, when a programmer makes a mistake and uses an obsolete member, a compile-time warning is displayed and explains to the programmer what they had done wrong.
Visual Studio is another great example because it lets you know when you have a syntax error even before you compile, using red squiggly underlines.
This also applies to those of you who don’t develop infrastructure code, because when your project enters the maintenance phase and if some one else was to maintain your code, they will make mistakes. Strongly type members. Use comments. Do not let them mistake.
The guidelines of Zero Trust have been with me all the way and helped me develop better software. I would recommend that you always have these two questions in the back of your mind:
- How can I force whoever uses this piece of code to make as few mistakes when using it as possible?
- How can cover the rest of the scenarios where I can’t force the user to do the right thing?
Maybe someday everyone will think like this.
Do you follow this school of thought as well? I’d like to hear what you have to say.