Why is it that VB (and VBScript) seems to be more prone to poor code styling than most other languages.

I suppose it’s likely because Basic is, if I recall correctly, the most widely used language out there. And if something’s that widespread, well, bad things are just bound to happen, and happen more often.

I was looking at some code recently (I read lots of code) and saw this (the function name and a few comments have been removed but otherwise this is exactly as I found it, and I’m not even concerned with what the code does for this purpose):

Function XXXX(Optional AutoRestart As Bo olean = True, Optional CreateNew As Boolean) As Boolean
InitCommonControls
On Error Resume Next
Dim XML             As String
Dim ManifestCheck   As String
Dim strManifest     As String
Dim FreeFileNo      As Integer

If cIDECheck = True Then AutoRestart = False
If AutoRestart = True Then CreateNew = False

XML = (" " & vbCrLf & "<assembly>" & vbCrLf & "<assemblyidentity>" & vbCrLf & "    <description>EXEDESCRIBTION</description>" & vbCrLf & "    <dependency>" & vbCrLf & "    <dependentassembly>" & vbCrLf & "    <assemblyidentity>" & vbCrLf & "    </dependentassembly>" & vbCrLf & "    </dependency>" & vbCrLf & "</assembly>" & vbCrLf & "")

strManifest = App.Path & "\" & App.EXEName & ".exe.manifest"    'set the name of the manifest
ManifestCheck = Dir(strManifest, vbNormal + vbSystem + vbHidden + vbReadOnly + vbArchive) 'check the app manifest file.
If ManifestCheck = "" Or CreateNew = True Then           'if not found.. make a new one
XML = Replace(XML, "EXENAME", App.EXEName & ".exe")             'Replaces the string "EXENAME" with the program's exe file name.
XML = Replace(XML, "EXEVERSION", App.Major & "." & App.Minor & "." & App.Revision & ".0") 'Replaces the "EXEVERSION" string.
XML = Replace(XML, "EXEDESCRIBTION", App.FileDescription)       'Replaces the app Describtion.
FreeFileNo = FreeFile      
If ManifestCheck <> "" Then
SetAttr strManifest, vbNormal
Kill strManifest
End If
Open strManifest For Binary As #(FreeFileNo) 'open the file
Put #(FreeFileNo), , XML    'uses 'put' to set the file content.. note that 'put' (binary mode) is much faster than 'print'(output mode)
Close #(FreeFileNo)         'close the file.
SetAttr strManifest, vbHidden + vbSystem
If ManifestCheck = "" Then
XXXX = False            
Else
XXXX = True
End If
If AutoRestart = True Then  
Shell App.Path & "\" & App.EXEName & ".exe " & Command$, vbNormalFocus  'restart the program and bypass command line parameters (if any)
End                         
End If
Else                'the manifest file exists.
XXXX = True      'return true.
End If
End Function

Now, I’m sure this code functions just fine and is probably quite useful, but how can even the guy that wrote this come back and read it, quickly, 6 months from now?

I indented the same code and took screen shots to compare them side by side (the highlighter is mine):

Note how the highlighter (and your eye) is naturally drawn into the curves of the indentation.

By comparison, the unindented code yields a straight line. There are no clues to tell your eyes where to look.

A guiding principle in feng shui is that straight lines are generally bad. Many books on the subject call them poison arrows because, it’s believed, straight lines tend to direct negative chi (energy) toward whatever they’re pointing at.

In the same way that you generally do not want an arrow straight walkway directly from the street to your front door, you do not want an arrow straight eyeball walkway that directs the eye right by the code it’s supposed to be reading.

Long story short, it’s good to be a lazy programmer, but it’s certainly possible to be too lazy.

Visual Basic’s got a bit of a bad rap as it is. A little less of this might go a long way towards helping that.