HATE IT: Yoda and GOTO

 

HATE IT is a new label for blog posts on the site. It is assigned to my rants about things that annoy me. It can be pretty much anything I experience or am exposed to in live as long as it annoys me.

This time in HATE IT I’d like to mention two programming concepts that sometimes feel like they were designed just to annoy me.

First off is Yoda Conditions. Yoda Conditions is defined as the act of using:

1
if(constant == variable)

instead of

1
if(variable == constant)

The purpose of using Yoda Conditions is to prevent assignment problems in boolean conditions where both = and == are usable in the language and one is used for assignments and the other for comparisons. That is most often redundant because most decent compilers and IDEs will warn you about the issue beforehand so basically if you choose to follow this logic the only thing you are doing is annoying everyone by making your code hard to read.

This whole thing is a bit like saying “If blue is the sky” (ergo the Yoda name). The real problem with people that follow this logic is they start using it for variable against variable checks which is just illogical and annoying.

1
2
3
4
5
6
7
if(maxValue == counter) {
    break;
}
else
{
    counter++
}

Just plain annoying to have to think in reverse.

The second annoyance is the requirement of GOTO as an error handling mechanisms in VBA. GOTO is an age old statement that’s part of various computer languages and allows the programmer to control the flow of his code by making jumps to specific line numbers or labels. In olden times it seemed like a good idea so it got used excessively but then people realized that this thing didn’t make for logical and easily readable code nor prevent stupid mistakes with code paths all over the place from the constant jumping. Ergo GOTO was declared the foul beast of the seven hells and the future would be in the hands of the structured program theorem.

Now a days the only thing the only thing new entries to programming are rarely told anything of GOTO except for maybe “There is this thing called GOTO, never ever use that crap”.

That being said there is still one place where a lot of people encounter this beast from the distant past and that is it’s requirement for proper error handling in VBA. A whole slew of people are forced to use VBA every day as it’s the go to language for quick and dirty programming solutions for Microsoft Office, be it for easy automation or modelling complex financial models. VBA is simply there, easy to get a basic handle off and easy to throw around since it’s locked into the document it’s coded into.

Now my annoyance and reason for going on this rant is that there is no way in VBA to put in error handling without the use of GOTO statements except maybe using very specific error checking.

The options available for

1
2
3
    On Error Goto 0
    On Error Resume Next
    On Error Goto <label>:

The first choice is also the built in default option and will enable a error dialog when your code does something “weird”. The second option will basically ignore the error and enable to you semi fix it but it needs to be very specific, e.g.:

1
2
3
4
5
    On Error Resume Next
    N = 1 / 0    ' cause an error
   If Err.Number <> 0 Then
        N = 1
    End If

So it basically just ignores the error and you’d need to have checks for all possibilities and fix them. Highly destructive and annoying. The third option is the bane of my existence:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Sub SomeProcedure()
    On Error GoTo ErrHandler:
    N = 1 / 0
    '
   ' code that is skipped if an error occurs
   '
   Label1:
    '
   ' more code to execute
   '
   Exit Sub

    ErrHandler:
    ' Handle error and then
   ' go back to the line at Label1
   Resume Label1:
End Sub

Doesn’t look to bad like that but think of how this scales? Getting a headache? Yes me too. Once there are multiple issues that can happen in the code this becomes highly unstable and ill manageable. But no that is what Microsoft wants us to live with so live with it we must. I wish I could get Try/Catch/Finally flow controls for VBA but I doubt that will ever happen. For now I’ll just grumble to myself and hope I manage to make my code defensively designed enough to be safe from what ever dodgy users can throw at it :)

That’s it for now, just be careful with GOTO.


No related posts.