New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguous line label identifier #408

Open
retailcoder opened this Issue Apr 22, 2015 · 2 comments

Comments

Projects
None yet
4 participants
@retailcoder
Member

retailcoder commented Apr 22, 2015

Consider this [bad but legal] code:

Public Sub DoSomething()
Foo: Bar
End Sub

Private Sub Foo()
End Sub

Private Sub Bar()
End Sub

The user's intent may have been to call both Foo and Bar procedures on a single line, but VBA will parse Foo: as a line label, and only Bar will be executed.

Rubberduck should warn when it encounters a line label identifier that matches a procedure name that's in-scope.

Possible quick-fix: Convert line label to procedure call - turn this:

Public Sub DoSomething()
Foo: Bar
End Sub

Into this:

Public Sub DoSomething()
    Foo
    Bar
End Sub

Another possible fix would be to introduce a Call statement:

Public Sub DoSomething()
    Call Foo() : Bar
End Sub

But that would fire up #34, and then applying the Remove obsolete Call statement quickfix would result in this code:

Public Sub DoSomething()
Foo: Bar
End Sub

In other words, this inspection solves an issue that an edge-case quickfix of #34 introduces in the user's code.

@daFreeMan

This comment has been minimized.

Show comment
Hide comment
@daFreeMan

daFreeMan Apr 22, 2015

Contributor

Since Call() serves no other valid purpose in VBA, as was discussed here, I'd say go with the first option:

Public Sub DoSomething()
  Foo
  Bar
End Sub
Contributor

daFreeMan commented Apr 22, 2015

Since Call() serves no other valid purpose in VBA, as was discussed here, I'd say go with the first option:

Public Sub DoSomething()
  Foo
  Bar
End Sub
@retailcoder

This comment has been minimized.

Show comment
Hide comment
@retailcoder

retailcoder Apr 22, 2015

Member

@daFreeMan indeed. I was merely documenting an oversight in the implementation of the quickfix for #34 😉

Member

retailcoder commented Apr 22, 2015

@daFreeMan indeed. I was merely documenting an oversight in the implementation of the quickfix for #34 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment