In general, it's more important to have some coding styles than to use a particular set of rules. Code that is consistent is easier to read, understand, debug, and maintain no matter what rules you use.
However, it amazes me how many developers seem to have no rules or rules that are inconsistent and contradictory. In one very large (56,000 line) project, I've seen people using arbitrary indentation, no comments, improper variable naming (for example, using an "m" prefix that normally means "module-level" for local variables), and so forth.
So here are the rules that I generally use. Adopt the ones that makes sense to you and replace the others. Note that these are the rules that I use for Visual Basic 6. I use slightly different rules for other languages, including VB .NET.
Here's some commented code by WJK showing some of his standards.
Private Sub DoesSomething(inString$, inInteger%)
Dim Integer%, String$
' I always use the variable types
' I know people disagree with this.
' I find it useful and better for me.
' Throughout the code I use the symbol.
' Always be aware of variable type.
' I do not use the variant variable type very often.
' In addition I use gVar to indicate Global Variables
' pVar to indicate module level public variables
' I always use txtTextBox, lblLabel, cbCheckbox
' etc. for controls
' An error statement is required at start of subroutine after Dim
' statement. Either format depending on subroutine, errs always handled.
On Error Resume Next
On Error GoTo DoesSomething_Error
' Name of err statement is always:
...sub code here...
' Labels are always to the left. Try to limit goto labels to one
' per subroutine... Goto statement can usually be avoided.
' I have some global err handlers, but many subs use this format.
Select Case Err.Number
Case xxx ' This handles specific occurrences, I try to write code to handle
' before error occurs, code executes faster when you do this.
Case Else ' Always an else case for handling most err types.
And here are some other tips by WJK.
- Always try to build a reusable subroutine to accomplish a given task. Never write the same inline code over and over. This makes your code easier to maintain and update (fix one, you fix all)
- I like the use of the : character only when used with a short if statement:
IF A=B Then B=C : A=C
- The inline if statement can be of tremendous use.
.Fields("Labor_Total_Cost") = Round((.Fields("Quantity") * _
IIf(.Fields("Labor"), 1, 0) * .Fields("Labor_Unit_Price") * _
.Fields("THE_FACTOR") * Currency_Value * gCCI_Labr), 2)
The inline if statement can eliminate having many additional intermediate
variables. If it can be done without inline if statements.... I do it that way.
- Working with record sets, I almost never use the notation:
recordset.fields(1) = xxxx
Instead I use:
It makes the code self documenting.
I'll add more to this list later.
For more tips and tricks for development, see my book Prototyping With Visual Basic.
Email me your suggestions and I'll consider adding them to the list.