I heard this one while working for a consulting company. The idea is that you write your base class, create an interface out of it (this is quite easy with todays refactoring tools) and then use the interface where possible instead of the base class.
This might look like an overhead to some of your colleagues but it will pay off in the end! I must say I don’t follow this though in day to day coding (there I do it when necessary), but it’s definitely worth doing in frameworks. It will come in very handy for people that need to provide a different implementation or if you need to implement your interface on a class that already inherits from somewhere else. I ran into this problem so many times and it is really hard to solve later on in a framework situation.
“Make all Methods virtual!” This was actually a sign on the door of the Head of Engineering in a company i used to work. I thought at the time this was a pretty extreme advice. It was actually targeted at the C++ programmers in our group but can be applied to C# as well. The background was that this guy used to be a Java programmer. In Java you have the opposite situation: Every method is virtual by default! You have to say explicitly that a method shall be final (non-virtual).
Now I came to the conclusion that this is a very good advice, especially if you are working on a framework. I had recently various situations where we had to change our framework simply because we needed to override a method. This is a big thing because you have to redistribute the framework, do tests etc.
The only downside of making everything virtual is a slight diminished performance (as the compiler needs to put hooks into your code to provide a possibility to override things). There is an excellent discussion about this on artima (http://www.artima.com/intv/nonvirtual.html) with Anders Hejlsberg. I definitely would argue, that it is worth following this “extreme advice”.
The Singleton pattern implementation out of the gang of four book [Gamma, Helm, Johnson, and Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.] is not thread save (at least in C# it isn’t). Besides that it uses a GetInstance() method and makes not use of C# properties. I think a simple Instance property is nicer and follows the general C# style.
Check out my version of a Singleton implemenation:
public class Singleton
private readonly static Singleton singleton = new Singleton();
public static Singleton Instance()
Upsides of this approach are that it is thread save and look quite simple. Downside is you don’t have exact control over when the Instance is created. In the few cases where this is important (Let’s say the creation of the instance is very time consuming and you want to guarantee that it is only created when needed you might want to check out the double-check locking approach more detailed explained here: http://msdn2.microsoft.com/en-us/library/ms998558.aspx.
The double-check locking approach is also a solution if you need to do some extra stuff when you create the one instance.
It’s easy: always use decimals for variables that represent money.
Reason to avoid floats or doubles: They will produce incorrect results when you try to calculate something. I have to add, it will produce errors in very rare cases. However you can avoid it by using decimals!
You don’t believe me? Try this: 77.1 * 850 should be exactly 65,535.
decimal correct = (decimal)77.1 * (decimal)850d;
correct will be = 65535
double incorrect = (double)77.1 * (double)850;
incorrect will be = 65534.999999999993
Why is that? That’s because 0.1 has no exact representation in binary… it’s a repeating binary number. It’s sort of like how 1/3 has no representation in decimal. 1/3 is 0.33333333 and you have to keep writing 3’s forever. If you lose patience, you get something inexact.
So what are the downsides to decimal?
- They use a lot more space, 128 bit to be exact. But who cares these days…
- They are slow as a dog. Again, doesn’t matter if you are not about to program your own spreadsheet application.