locked
VB Coding Standards: Are, CInt, CBool, CStr, CDate and the remaining methods now obsolete? RRS feed

  • Question

  • User492859122 posted

    I hope that someone can help to provide me with information.

    An interesting, "conversation", has occurred whereby I was informed that the methods (?) CInt, CBool, CDate etc are now considered obsolete when converting our variables from one type to another.

    Please would someone confirm or deny this giving evidence from Microsoft?

    Thanks, mrPlatpus

    Wednesday, November 18, 2009 5:50 AM

Answers

  • User-952121411 posted

    This is a really interesting conversation, as I have been doing VB6 and VB.NET the majority of my career with C# for a few years when I started .NET   I always thought of those functions (Cint, CBool, CDbl, etc) to exist in .NET for (2) reasons:

    1. To help convert VB6 code to .NET, thus encouraging developers to move to .NET
    2. For a comfort of familiarity for VB6 to .NET developers.  Along these lines the Microsoft.VisualBasic namespace in .NET offers an extended amount of methods that existed in VB6 and to help VB6 developers migrate and feel comfortable coding in .NET

    Now in regards to the last excerpt from the MSDN (Type Conversion Functions: http://msdn.microsoft.com/en-us/library/s2dy91zy(VS.80).aspx):

    "As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read."

     That is really interesting.  I have always tried to not use those functions in favor of using the .NET conversion functions (i.e. Integer.Parse, or DateTime.Parse) for the reason that I want to be flexible in development and move back and forth between C# and VB.NET when needed.  By doing things 'The .NET Way', I figured it would allow me to switch between languages more easily.

    For example, if I was a stubborn VB6 coder that moved to .NET but used all of the types and methods from VB6, what would be the point?  Wouldn't that be ridiculous to write a VB.NET program that used classic ADO and VisualBasic specific syntax?  Yes it might work, but might as well stay in VB6 if I was going to do that.  Not that anyone here was down this path, but it is the though process behind using VisualBasic specific methods and syntax or finding the .NET method of doing the same task.

    I can tell you in many years of VB.NET development I have never had any bad conversion results or issues with using any of the Conversion methods provided by .NET.  So the following excerpt:

    "In addition, the .NET Framework conversion methods do not always produce the same results as the Visual Basic functions..."

    ...has not really applied to me, because I usually write my code from scratch.  I think this would be more of an issue if someone took an old VB6 app and started changing all of the conversion calls to the .NET equivalent.  In this case the conversion may not preform as expected.

    With this all said, I still prefer to use the .NET conversion methods in the core System namespace as opposed to the VisualBasic specific ones.  I don't think it is bad to use but I tend to prefer .NET when possible.  Another thing this reminds me of was when VB6 developers were 1st introduced to StringBuilders.  You had guys saying:

    "Why do I want the overhead of instantiating an object when I can use the ampersand sign to concatenate."

    Well that conversation is a little more indepth than that, but I can sum of some of the reasons VisualBasic has so much coding and syntax Grandfathered in the Microsoft.VisualBasic namespace.  It is to make old VB6 developers comfortable and migrate to VB.NET.  Remember roughly 10 years ago VisualBasic was one of the most widely used languages in the world (according to what I have read) with 3-6million estimated users.  Not all of those users have migrated, and some refuse to this day.

    Look at some of the following links:

    http://classicvb.org/petition/

    http://vb.mvps.org/

    http://visualstudiomagazine.com/articles/2009/10/27/microsoft-vb6-support-strategy.aspx

    Hope this information helps! Smile

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, November 19, 2009 12:32 PM
  • User-952121411 posted

    Well I must re-iterate because based on David's last comments I may have been partially misunderstood.  I don't think there is a 'wrong' way of doing the conversions.  Either method is acceptable, and as the MSDN pointed out, using the language's native methods may actually be preferable.  Let me quote a comment from my last post:

    I have always tried to not use those functions in favor of using the .NET conversion functions (i.e. Integer.Parse, or DateTime.Parse) for the reason that I want to be flexible in development and move back and forth between C# and VB.NET when needed.  By doing things 'The .NET Way', I figured it would allow me to switch between languages more easily.
     

    So as you can see my opinion on this topic was based on preference, and really using either methodology is a preference.

    I never hear C# programmers mention that casting with the built-in syntax casting should be abandoned in favor of .NET methods...

    David- another thing about your comment on C# developers; I think a huge difference is that the majority of migrated C# developers either came from C++ which is a low level powerful OOP language or maybe Java another strong OOP language. VB6 was neither. Most VB.NET programmers came from VB6 or prior which was not a truly OOP language and had been looked at sometimes as a language where something could be put together quick and dirty.  Therefore the tendency to shed practices from VB6 is going to be quite a bit more common than those that developed in C++ or Java and migrated to C#.  Hence the reason you do not hear about a lot of C# programmers having discussions on ways to abandon old practices.

    mrPlatypus- in the end it is just preference.  I stated my thoughts on why I tend to try and stay in the middle of the .NET languages when possible for my reasons, but they do not apply to everyone.  Like you said good conversation and you received some good information.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 20, 2009 8:51 AM

All replies

  • User541108374 posted

    Hi,

    it's indeed advised to use CType and DirectCast instead.

    It's been a long while that I did VB.NET but you can turn on Option Explicit and Option Strict

    Grz, Kris.

    Wednesday, November 18, 2009 6:05 AM
  • User492859122 posted

    Hi Kris,

    Thanks for replying so promptly.  I for one have always advocated the use of Option Explicit and Option Strict and I would not want to code otherwise either.

    The advice given was that we should be using, "<type>.Parse", and "Convert.<type>".

    I was explicitly informed that the elder methods are obsolete (?) and Microsoft will be deprecating them if not already.

    Would you and other fellow developers agree?

    When did the notification come from Microsoft to say that the elder methods are being deprecated, does anyone have or know of a link?

    Thanks

    mrPlatypus

    Wednesday, November 18, 2009 7:37 AM
  • User541108374 posted

    Hi,

    "<type>.Parse", and "Convert.<type>".

    Those, besides the ones I proposed, are indeed also encouraged to use.

    When did the notification come from Microsoft to say that the elder methods are being deprecated, does anyone have or know of a link?

    I don't know about a notification but I always heard to not use the CInt and related things since Visual Basic.NET 1.0 in 2002.

    Grz, Kris. 

    Wednesday, November 18, 2009 7:47 AM
  • User492859122 posted

    Kris,

    If what you have heard is correct:

    I don't know about a notification but I always heard to not use the CInt and related things since Visual Basic.NET 1.0 in 2002.

    If what have always heard i.e. not to use CInt etc, why would you think that Microsoft would have included a section in the .Net Framework 2.0 Training Kit on, "Converting Between Types", which says that, "CBool, CInt, CStr etc convert base Visual Basic types; compiled inline for better performance (Visual Basic only.)."??


    Maybe I am stuck in the dark ages and need to come into the vb.net world a lot more?

    I hope to read from other readers of this website on this topic too ..

    Looks like its humble pie for me.

    Regards

    mrPlatypus

    Wednesday, November 18, 2009 8:09 AM
  • User397347636 posted

    These are not obsolete.

    CInt, CBool, etc. are just shorthand for the equivalent CType.

    All of these are built-in VB operators, not library methods, and are not obsolete.

    These shorthand casting methods, in addition to CType, DirectCast, and TryCast, are the way that you cast in VB.  Without them, you would have no way to cast within the VB language (without resorting to library methods).

     

    Wednesday, November 18, 2009 10:59 AM
  • User492859122 posted

    These are not obsolete.

    CInt, CBool, etc. are just shorthand for the equivalent CType.

    All of these are built-in VB operators, not library methods, and are not obsolete.

    These shorthand casting methods, in addition to CType, DirectCast, and TryCast, are the way that you cast in VB.  Without them, you would have no way to cast within the VB language (without resorting to library methods).

    All: I have read the forums.asp.net article:  http://forums.asp.net/p/681608/681796.aspx; where, "Andre Colbiornsen", claims: 

    Use Int32.Parse() or Convert.ToInt32(). CInt() is obsolete.

    David: What you are saying is that there is no need to rewrite code which uses these built-in VB operators to make use of <type>.Parse and Convert.To<type> to future proof applications code?

    All: I have read the Microsoft Article: http://msdn.microsoft.com/en-us/library/s2dy91zy.aspx; which states:

    As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read. In addition, the .NET Framework conversion methods do not always produce the same results as the Visual Basic functions, for example when converting Boolean to Integer.

    Wednesday, November 18, 2009 11:25 AM
  • User397347636 posted

    Yes - you do not need to rewrite.

    The link you posted is simply someone's opinion on how to perform casting in VB.  They were incorrect to have stated that the built-in VB casting was obsolete.

    Microsoft is simply not going to remove built-in language support for casting in VB.   Every language has built-in casting support - it's ridiculous for anyone to suggest that it will be removed.

    Again, CInt, CBool, CType, etc. are part of VB's syntax and are there to provide casting in VB.  They will not be removed.

    Wednesday, November 18, 2009 11:32 AM
  • User541108374 posted

    They will not be removed
     

    Just to add my 2 cents to this part: most likely not for backward compatability. However I think it's still adviced to use the more .NET castings like convert, parse, tryparse, ... as it'll make it easier to switch to another .NET enabled language. It sure did for me when I made the switch to C# in the past.

    Grz, Kris.

    Wednesday, November 18, 2009 11:44 AM
  • User492859122 posted

    Just to add my 2 cents to this part: most likely not for backward compatability. However I think it's still adviced to use the more .NET castings like convert, parse, tryparse, ... as it'll make it easier to switch to another .NET enabled language. It sure did for me when I made the switch to C# in the past.

    Grz, Kris.

    Kris: I refer you to my previous post where Microsoft claim:

    As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read. In addition, the .NET Framework conversion methods do not always produce the same results as the Visual Basic functions, for example when converting Boolean to Integer.

    Everyone: Please add to this thread with your opinions and evidence where possible.

    Thanks & Regards

    Dave

    Wednesday, November 18, 2009 12:01 PM
  • User-952121411 posted

    This is a really interesting conversation, as I have been doing VB6 and VB.NET the majority of my career with C# for a few years when I started .NET   I always thought of those functions (Cint, CBool, CDbl, etc) to exist in .NET for (2) reasons:

    1. To help convert VB6 code to .NET, thus encouraging developers to move to .NET
    2. For a comfort of familiarity for VB6 to .NET developers.  Along these lines the Microsoft.VisualBasic namespace in .NET offers an extended amount of methods that existed in VB6 and to help VB6 developers migrate and feel comfortable coding in .NET

    Now in regards to the last excerpt from the MSDN (Type Conversion Functions: http://msdn.microsoft.com/en-us/library/s2dy91zy(VS.80).aspx):

    "As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read."

     That is really interesting.  I have always tried to not use those functions in favor of using the .NET conversion functions (i.e. Integer.Parse, or DateTime.Parse) for the reason that I want to be flexible in development and move back and forth between C# and VB.NET when needed.  By doing things 'The .NET Way', I figured it would allow me to switch between languages more easily.

    For example, if I was a stubborn VB6 coder that moved to .NET but used all of the types and methods from VB6, what would be the point?  Wouldn't that be ridiculous to write a VB.NET program that used classic ADO and VisualBasic specific syntax?  Yes it might work, but might as well stay in VB6 if I was going to do that.  Not that anyone here was down this path, but it is the though process behind using VisualBasic specific methods and syntax or finding the .NET method of doing the same task.

    I can tell you in many years of VB.NET development I have never had any bad conversion results or issues with using any of the Conversion methods provided by .NET.  So the following excerpt:

    "In addition, the .NET Framework conversion methods do not always produce the same results as the Visual Basic functions..."

    ...has not really applied to me, because I usually write my code from scratch.  I think this would be more of an issue if someone took an old VB6 app and started changing all of the conversion calls to the .NET equivalent.  In this case the conversion may not preform as expected.

    With this all said, I still prefer to use the .NET conversion methods in the core System namespace as opposed to the VisualBasic specific ones.  I don't think it is bad to use but I tend to prefer .NET when possible.  Another thing this reminds me of was when VB6 developers were 1st introduced to StringBuilders.  You had guys saying:

    "Why do I want the overhead of instantiating an object when I can use the ampersand sign to concatenate."

    Well that conversation is a little more indepth than that, but I can sum of some of the reasons VisualBasic has so much coding and syntax Grandfathered in the Microsoft.VisualBasic namespace.  It is to make old VB6 developers comfortable and migrate to VB.NET.  Remember roughly 10 years ago VisualBasic was one of the most widely used languages in the world (according to what I have read) with 3-6million estimated users.  Not all of those users have migrated, and some refuse to this day.

    Look at some of the following links:

    http://classicvb.org/petition/

    http://vb.mvps.org/

    http://visualstudiomagazine.com/articles/2009/10/27/microsoft-vb6-support-strategy.aspx

    Hope this information helps! Smile

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, November 19, 2009 12:32 PM
  • User397347636 posted

    I never hear C# programmers mention that casting with the built-in syntax casting should be abandoned in favor of .NET methods...

    e.g., you never hear anyone say "use Convert.ToInt32 rather than (int)"

    Every language has support for casting - CInt, CBool, etc. are VB's language support.

    True - it was in VB6, but so was "If", "For", "Sub", etc.

     

    Thursday, November 19, 2009 7:38 PM
  • User492859122 posted

    atconway : thanks very much for your contributions.

    David Anton: Thanks again for your contributions.


    You have both raised some interesting points.


    Would anyone else like to contribute as I would really value reading them.


    Thanks, mrPlatypus (aka Dave)

    Friday, November 20, 2009 4:29 AM
  • User-952121411 posted

    Well I must re-iterate because based on David's last comments I may have been partially misunderstood.  I don't think there is a 'wrong' way of doing the conversions.  Either method is acceptable, and as the MSDN pointed out, using the language's native methods may actually be preferable.  Let me quote a comment from my last post:

    I have always tried to not use those functions in favor of using the .NET conversion functions (i.e. Integer.Parse, or DateTime.Parse) for the reason that I want to be flexible in development and move back and forth between C# and VB.NET when needed.  By doing things 'The .NET Way', I figured it would allow me to switch between languages more easily.
     

    So as you can see my opinion on this topic was based on preference, and really using either methodology is a preference.

    I never hear C# programmers mention that casting with the built-in syntax casting should be abandoned in favor of .NET methods...

    David- another thing about your comment on C# developers; I think a huge difference is that the majority of migrated C# developers either came from C++ which is a low level powerful OOP language or maybe Java another strong OOP language. VB6 was neither. Most VB.NET programmers came from VB6 or prior which was not a truly OOP language and had been looked at sometimes as a language where something could be put together quick and dirty.  Therefore the tendency to shed practices from VB6 is going to be quite a bit more common than those that developed in C++ or Java and migrated to C#.  Hence the reason you do not hear about a lot of C# programmers having discussions on ways to abandon old practices.

    mrPlatypus- in the end it is just preference.  I stated my thoughts on why I tend to try and stay in the middle of the .NET languages when possible for my reasons, but they do not apply to everyone.  Like you said good conversation and you received some good information.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 20, 2009 8:51 AM