|
Continuing on from last week's VB Coding Standards
Update(1), in preparation for the next version of Visual Basic, due for release
H2, 2001, some fundaments VB coding approaches will have to
change to accommodate VB.NET. Here are more simple changes which are
required for VB.NET, and can be integrated into current versions of VB.
One thing is for sure, most of your current programs will not run in
VB.NET without some manual intervention, so employing these coding
procedures would make the migration easier.
Variable Declarations:
The rules defining variable declarations are to change, by including
new syntax and not supporting some of the current syntax. Multiple
datatype declarations can be coded on one line as follows:
Dim strName as String, intAge as Integer, decSalary as Decimal
While default datatype declarations such as:
Dim Wage, ShoeSize as Integer
where Wage would have become Variant in VB6, will become Integer in
VB.NET. Unless screen space is a real issue, play safe and declare
variables on separate lines.
Currency and Variant Datatype to go:
VB.NET will no longer support currency and variant datatypes. Currency
will be replaced with the new 64 bit Long datatype (or Decimal datatype). NOTE:
Datatypes cannot be declared as Decimal, but can be converted
using cDec to make them a Decimal subtype.
Variant datatypes are to be replaced with Object datatypes for most
purposes, but best avoided if possible, especially where a more
appropriate datatype can be employed.
API Call Arguments:
As the Long datatype in VB.NET will be 64 bit, and Win32 API calls
accept 32 bit Long arguments, most API calls will fail unless these
arguments are re-declared as the new Integer datatype. To clarify....
VB6's Integer will become 'Short' in VB.NET; VB6's Long will become
'Integer' in VB.NET; and VB.NET new 64 bit 'Long' doesn't have an equivalent
in VB6.
Split out your Business and Presentation Logic
Look for opportunities to encapsulate your logic in classes, as
classes are the easiest modules to migrate to VB.NET. Where your
applications are based around rich clients containing a mixture of
business and presentation logic, these will prove the most difficult to
accommodate. Ideally, the more logic you have in components and classes,
and the thinner client, the better. This is due to the introduction of
WebForms and WinForms, and a greater distinction between the UI and code components/classes.
|
