More on BCL type names

Jeff read my
recent post
and suggested I include ALL his reasons for using the BCL
name...  Here are they are...

1.
Devs think there is a
difference between String and string or int and Int32
and there isn’t. For example, I’ve run into some people who think that string
(lowercase ‘s’) is a string allocated on the stack
while a String (uppercase S) is a string allocated on the heap. All kinds of
crazy codes results from this incorrect assumption.= "urn:schemas-microsoft-com:office:office" />

2.
Code written using the
BCL names can more easily be interpreted/ported by
devs working in a different language. Since the
compiler primitive types exist, devs HAVE to know that
there is a mapping between long and Int32 for C# and long and Int64 for MC++
(for example). So, someone porting code (even just mentally) from one language
to another has to know BOTH compiler mappings.

3.
The CLR doesn’t know
about the primitive types. So, Type.GetType(“int”) will never work in any language but Type.GetType(“System.Int32”) always works in all languages.
Many programmers don’t understand why the primitive type name works in one
context but not in another context.

4.
The BCL has many
methods with type names as part of the method name itself. If “br” is a BinaryReader then, in C#,
you can say float value = br.ReadSingle(); which is
technically correct but it feels very unnatural. I prefer Single value = br.ReadSingle(); which looks and feels right. Again, this makes the code
easier to write, maintain, and understand. Using “float” is requiring the
programmer to know more and just makes things more
difficult.