The var keyword let you declare a local variable implicit. During compilation, the type of the variable is determined. It allows you to quickly define a variable, where the type of the variable is trivial. Using the var keyword can lead to some discussion when code guidelines are made up, since some people say it makes programming easier but people may also argue that code is less readable. Read More…
Posted in
Best practices,
C# at June 25th, 2015.
No Comments.
When it comes to constructors, I always suggest not using any code in the constructor except the code that initializes local members. All other code could possibly throw an exception. Use only the constructor to pass the parameters to its local members. The reason behind this is, when an exception occurs, the calling party retrieves a null pointer. This misuses the main purpose of a constructor, namely allocating memory and returning a pointer to the new created instance.
Read More…
Posted in
Best practices at March 12th, 2014.
No Comments.
Design by contract is a technique, introduced by Betrand Meyer and applied within the Eiffel programming language. The concept allows a programmer to document the rights and responsibilities of everyone who uses your code. A contract (not to be confused with a .Net WCF contract) can contain the following elements:
- A precondition;
- An invariant;
- A postcondition.
Preconditions state the conditions that must be met in order to enter the method. For example a parameter “i” must have a positive value. Postconditions describe the conditions of the result of the method. An invariant states the condition which will be always be true, seen from a perspective from the calling party. Using the pre-, postconditions and invariants you can also show the correctness of a program. Read More…
Posted in
Best practices,
C# at March 3rd, 2013.
No Comments.
Defensive programming is important when it comes to building robust applications: you simply test the information which is coming in. Within an application you couldn’t simply say “Garbage in is garbage out”. You’re method should be robust, and in case of an error even log this problem. The values that you’re method will accept are the so-called preconditions of your method. These preconditions are also used by programming by contract.
When it comes to defensive programming. It is important to test all your public methods on the information that is passed. For example when you get passed an object, you want to check if the object is not null. Or when you’re writing a method that calculates a temperature from Kelvin to Celsius, you simply test if the provided temperature in Kelvin doesn’t exeed the 273 degrees.
On the other hand private members doesn’t realy need to be programmed defensive, since you are only the one who is calling these internal methods. Terefore it should be better to use assertions within your private members. Assertions will only be active within a debug build and throw an exception if the condition of the assertion is not met.
How do you handle an error that you do not expect to occur? If there is really, really something wrong you can’t deal with at the current level you throw an exception. You should however always try to fix the error locally. In all other cases you best return a decent value or provide an error code. When for example you’ve created a method that only excepts digits smaller than 10, you could argue that if someone is passing the number 11, your application uses 10 internally.
Posted in
Best practices at June 27th, 2012.
No Comments.