I just saw this posted by @RubberduckVBA on Twitter and couldn’t resist sharing it on here. Did you know that this VBA code will compile and run correctly?
Public Property Get Foo() As String
Foo = "WTF!"
End Function
And, perhaps even scarier, so will these (and variations thereof):
Public Property Get Foo2() As String
Foo2 = "WTF!"
End Sub
Public Property Get Foo3() As String
Foo3 = "WTF!"
Exit Function
Exit Sub
End Property
RAD Excel 
Thanks for sharing!
FWIW an issue was created to attempt to get Rubberduck’s parser to pick this up and perhaps fire up an inspection result with a quick-fix to make it right, but changing the parser rule for a property block to allow it to be terminated by either END_PROPERTY, END_SUB or END_FUNCTION tokens resulted in a broken parser; the issue was closed as “status-declined” – so this code makes Rubberduck report a parser error… which VBA itself should arguably be reporting as a compile error.
Note that the VBE auto-corrects the faulty statements the minute you indent/outdent the property, so to have such code in your VBA project you need to actually fight the IDE a little – enough for us to say “dude, you asked for it”.
It just itches to know there’s “valid” VBA code that we still can’t parse. I wonder if VB6 has/had the same bug now…
LikeLike
What’s the problem, Microsoft is trying to dumb down VBA so it is accessible to the masses! Coding is no longer important. You’ll be able to write anything and it will work.
It is sad. Microsoft is releasing their software now littered with bugs, many long standing ones and wait for the public to report problems and only then address (and I use that word very lightly) them if enough people make noise. They seem to have done away with Quality Assurance and proper testing.
Such a bug, as you report, should never have made it out the door. My money’s on nothing will be done about it because it doesn’t actually stop anything from functioning.
LikeLike