Fun with VB6 ambiguity
-
Josh was a just-out-of-college guy who seemed to have a self-proclaimed expertise in
everything... His degree in Graphic Arts made him the resident know-it-all on every
subject, especially object oriented design (???). This was really amusing when he
declared his VB6 code to be the epitomy of OO standards.
Then we looked at some of the code. Here are 2 nice examples of declarations that
backfired on Josh, but it a fortunate way. Every method he used in these objects
was able to be used implicitly as static (not explicitly declared!). Josh got very
lucky that his code just happened to work for him and that he never had to reference
multiple instances of LoginPattern or ProfileTree.
<code>
Private LoginPattern As New LoginPattern
Private ProfileTree As New ProfileTree
</code>
If naming a variable the same as its declared type wasn't bad enough, he had an
interesting grasp on naming convention in his forms as well. Following typical
convention, he named forms with a "frm" prefix (eg. frmError). Each form usually
had at least one frame on it. In just one of many cases, 'frmError' was a frame on the
form 'frmError'. Wow…
We were all astonished and impressed that VB6 could handle his ambiguous ideas. It
seems that VB6 either caters well to goofball programmers, or it is more robust than
people give it credit for (the jury is still out on that one…).
Side note:
Some of the other highlights Josh became famous for were his monstrous method signatures.
Coupling was never a consideration when he decided to pass a form AND its buttons (as
variants - ?) AND its frames AND its textboxes AND its labels, and a db connection info between methods:
<code>
Public Sub loadSelectedCase(fOracle As FooOracle,
userRoles As Dictionary,
ByVal caseId As String,
frmCase As Form,
entityTree As treeView,
lstStatus As ListBox,
frmSynopsis As Frame,
frmFields As Frame,
lblSynopsis As Label,
txtSynopsis As TextBox,
cmdSynopsis As Variant)
</code>
...and then there's the mystery db recordset check:
<code>
Public Function validateRecset(recset As OraDynaset) As Boolean
If recset Is Nothing Then
validateRecset = False
ElseIf recset.RecordCount <= 0 Then
validateRecset = False
End If
validateRecset = True
End Function
</code>
Even though he invalidates his validation by claiming every recordset is valid, I'm glad he's thorough enough to check for those times when the RecordCount would be less than zero.
-
He is future-proofing his code for when databases will support negative information.
-
@scooter said:
...and then there's the mystery db recordset check:
Public Function validateRecset(recset As OraDynaset) As Boolean
If recset Is Nothing Then
validateRecset = False
ElseIf recset.RecordCount <= 0 Then
validateRecset = False
End If
validateRecset = True
End Function
Even though he invalidates his validation by claiming every recordset is valid, I'm glad he's thorough enough to check for those times when the RecordCount would be less than zero.
I don't know about OraDynaset, but with ADODB.Recordset, RecordCount will return -1 if the recordset was opened with certain cursor types. As for the rest of his code...yeah, it's pretty "special."
-
@UncleMidriff said:
I don't know about OraDynaset, but with ADODB.Recordset, RecordCount will return -1 if the recordset was opened with certain cursor types.In which case, the function would consider that an invalid recordset. So this code sucks that much more.
-
@A Wizard A True Star said:
@UncleMidriff said:
I
don't know about OraDynaset, but with ADODB.Recordset, RecordCount will
return -1 if the recordset was opened with certain cursor types.In which case, the function would consider that an invalid recordset. So this code sucks that much more
Actually, this function would consider the string "Fancy Pants" a valid recordset. :-)
Anyway, the original poster seemed to be indicating that he thought it
absurd to test for RecordCount < 0. I was just pointing out that
that's not such a crazy thing to do, at least not with ADO. Of course,
this particular example is full of WTF.
