Mixed Variable Types

Some languages like VB and VBScript allow for what is commonly referred to as "evil coercion" meaning that the system will do it's best to do automatic type conversion between two variable types.

This can be helpful in situations like this:

Dim x As Integer
Dim s As String

s = "7"

x = s 'No need to call Convert functions

But this can also cause major problems, especially in VBScript where variables aren't explicitly typed and everything is a "Variant", meaning a variable that can dynamically change it's internal type.

In these cases if you don't explicitly stick to rules of variable handling, initialization and comparison, you can run into serious logical errors, as well as confuse anyone trying to troubleshoot your code.

Sad Code:

'Variable is prefixed with "int"
'and value is initialized to a number
'but in quotes so it's treated as a string
Dim intNew : intNew = "0" 

'The database bit field is a Boolean,
'so the variant intNew should change to act like a Boolean
intNew = objRSLeadStage("bNew") 

'What's going to happen here?
'Is intNew a string, boolean or number?
If (intNew = "True") Then

Oddly enough, the above Sad Code works, in the sense that the comparison between the string value "True" coerces to the Boolean value True for the If statement.

The intNew variable here clearly has an identity crisis, and anyone trying to debug this code amongst a thousand other lines is most likely going to end up pulling there hair out asking WHY?

So remember that when you're working with dynamic variable types like Variants or Objects, and languages that perform evil coercion you should be VERY strict with how you handle your data types and variable names to avoid confusion.

Happy Code:

Dim bNew : bNew = False

bNew = CBool(objRSLeadStage("bNew"))

If (bNew) Then

As you can see here, there is no confusion in any area as to the behavior of your variable.

Documentation

I'm a big fan of what they call "Self Documenting Code" meaning code that is so straightforward and simple that just about any programmer could understand based on variable names, function names, context etc.

But of course there are times when you may have to write complex algorithms, or you're working in a module that's very large and you have to put in documentation to help make it easier for you or someone else to troubleshoot your code in the future.

Just make sure that your documentation is accurate and correct and belongs where it is in the code!

The only thing worse than NO documentation is INCORRECT documentation.

Trying to troubleshoot a function assuming that the comments are accurate only to find out later they are out of date or just copied and pasted from a different non applicable section can really drive you crazy!

Boolean Variables

Don't use non-Boolean data types for Boolean type operations.

i.e. Don't create a string variable and then check if it's equal to "Yes", "True", "On", or an integer variable and check for 1.

If the your flag is contained in a session variable or textbox, just declare a Boolean variable and use it going forward.

Sad Code:

If (sAccess = "Yes") Then
 'Go ahead

Happy Code:

Dim bAccess: bAccess = False

If (sAccess = "Yes") Then bAccess = True

If (bAccess) Then
 'Go ahead

Variable Declarations

1. Declare your variables outside of Try / Catch blocks

- AND -

2. Don't initialize your variables in the declaration block.

1 - If you declare your variables inside your Try Catch block you won't be able to access them at exception time.

Sad Code:

Try
 Dim MyString As String

 MyString = "Hey"

Catch ex As Exception
 'Can't view value of MyString here
End Try

Happy Code:

Dim MyString As String

Try
 MyString = "Hey"
Catch ex As Exception
 Response.Write(MyString) 'Yay!
End Try

2 - If you initialize your variables when you declare them, there are two issues.
A - You are creating objects that may never get used
B - Since your declarations are outside the try / catch blocks, you could throw an unhandled exception

Sad Code:

Dim MyObj As New CustomObject() 'Oops, this could cause an error!
Dim MyString As String

Try
 MyString = CInt("Hey") 
'Or it could get thrown out because
'this error happened before it was used

Catch ex As Exception
 'Stuff
End Try

Happy Code:

Dim MyObj As CustomObject 
Dim MyString As String

Try
 MyString = CInt("Hey")
'Now if we get an error here,
'we haven't wasted valuable resources!

 MyObj = New CustomObject()
'Yay! We waited until we needed the object to create it!

Catch ex As Exception
 'Stuff
End Try

HTML Tags

Don't leave HTML tags open, or close HTML tags that aren't there.

Sure you can write Sad Code like this:

<%
If (HasAccess) Then
%>
      <a href="Secure.asp">
<%
End If
%>
      Secure Link</a>

and it will most likely still show a link, but look at the messy source!

-- If HasAccess = True:
Secure Link

Source:

<a href="Secure.asp">Secure Link</a>

-- If HasAccess = False:
Secure Link

Source:

Secure Link</a>

That little closing anchor tag is not a happy tag!

Wasted Objects

Don't create objects unless you need them

Sad Code:

Dim MyTable As New DataTable 'Creates 1st data table

MyTable = MyFunction.GetDataTable()  'Destroys 1st data table and creates another

Happy Code:

Dim MyTable As DataTable

MyTable = MyFunction.GetDataTable()

Or if you prefer the quickie version:

Dim MyTable As DataTable = MyFunction.GetDataTable()

Naming Conventions

Do not name your local variables or subroutine arguments the same as your module level variables.

i.e.

Sad Code:

Private MyVar As Integer

Public Sub MySub(ByVal MyVar As Integer)

Also Sad Code:
Public Sub MySub()
 Dim MyVar As Integer

Tip: Use a character prefix to define the scope and type of your variables.

Happy Code:

Private mnVar As Integer

Public Sub MySub(ByVal vnVar As Integer)
 Dim nVar As Integer