A little ‘bit’ more on Int32 vs Integer


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 issues to 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
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.

Author: Duncan Mackenzie

I'm the Developer Lead for the Channel 9 team, formerly worked on MSDN as a developer, content strategist and author.

Leave a Reply

Your email address will not be published. Required fields are marked *