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.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.