Darren’s comments on my previous post:

I certainly don’t want to get into a debate over this but, shouldn’t the question be: “what is it best to use?”. I’m probably biased because I never really programmed in any typed languages before .NET, but, to me at least, being as explicit as possible is always a good thing. I know that Int32 will map to System.Int32 even in version 30 of the Framework. God knows what Integer or int will map to by then.

Instead of replying back to him directly or in the comments, I thought I would try replying in another blog entry (there certainly are some issuesto be worked out regarding the best way to comment/discuss)..

Good point Darren, thanks. The problem I see is that the question of “best” isn’t an easy one to answer. If you are writing your code to be dependent on the size of the underlying data type, then the desire to be explicit is certainly understandable, but when programming in C# or VB.NET you do not always need to be aware of this implementation detail. (that hurt to even type, I’m a big fan of always knowing about the details… but my point is that you shouldn’t have to know about them in this case). In fact, I think you should try to avoid being implementation dependent as a general rule.

As I mentioned in my last post, if I’m working in a situation, such as a Win32 API call, where the exact size of the integer, the number of bits involved, is relevant then I use it. In all other situations, I need to know that my data type (Integer) is big enough to hold the range of values I want to work with. Personally, I noticed and even wrote about the fact that Integers and Longs have changed from VB6 to VB.NET, but that change has had almost no effect on most VB6 code upgraded to VB.NET, except when calling out to external libraries. So, if in future implementations of the VB.NET compiler, they decide that (for efficiency on the standard processors of the day, perhaps) Integer should map to Int64, then I would hope that wouldn’t cause me much of a problem… if they decided, and I don’t think they would, to change the mapping to Int16, then I think I would be screwed.

Right after the PDC in 2000, I had just installed the .NET Framework “alpha” onto a machine and was busily writing a book on VB.NET… I decided that I should always use fully qualified types (System.Text.StringBuilder, instead of using an Imports and then just StringBuilder)… .NET was so new to many people that I wanted to err on the side of clarity. I also decided that I shouldn’t use things like Integer or MsgBox and that I should instead use System.Int32 and System.Windows.Forms.MessageBox.Show()… in time though I realized that I prefer to work with the terms/keywords that I am familiar with, and that even with Intellisense, I prefer to work with relatively short and easy to remember terms as well. So, now I use Imports for common namespaces (on a code file by code file basis, I really find the “default” Imports in VS.NET confusing) and I use language specific data types. I think that this is natural for people, and I wouldn’t want to try and change developers to Int32 or to change VB6 developers so that they stop using MsgBox(“Test”). Developers have habits; for example, I still use hungarian notation in lots of my own code (sorry Brad, I did read the design guidelines, I really did… I even use FxCop… my public members are generally ok, I just can’t stop using hungarian in my private variables!) even though it is no longer recommended.

I am still undecided about using fully qualified types in samples, sometimes people copy/paste a snippet of code from one of my articles that it is not a complete class or code file (and therefore does not include any Imports statements) and get quite confused when it doesn’t compile and they have all of these squigglies under the class names. When I can write code samples in such a way that the required Imports are automatically attached (even to a single code snippet) then I won’t have to use fully qualified class names, but for now I think I will have to change my coding style for snippets.

Darren, you said you didn’t want a debate and here I am replying with such a long post… but there really is no debate, at least not from me. I don’t know what the “best” way is, I just hope that some of my comments help explain why I have chosen a certain set of coding rules.