How the subroutine got its parenthesis

EricLi does a good job explaining why we started requiring parenthesis around subroutine calls in VB.NET, among other things. Back in the day, we would regularly get a bug report about every month or so complaining that "ByRef parameters aren’t working!" The problem would inevitably be that the developer was calling a subroutine with one parameter and using parenthesis. These bug reports came from both inside and outside of the company, and that wasn’t even counting all the sample code that I saw where people would include incorrect parenthesis and it ended up just not mattering (or the bug wasn’t caught yet). Even after working with Visual Basic code for years, I spent one afternoon trying to figure out why my ByRef param wasn’t behaving as ByRef…

(Minor sidenote: there actually isn’t a special rule about parenthesis making a parameter be passed ByVal, it’s just a side effect of the language. The parenthesis operator is a grouping operator that just evaluates to the value of whatever’s inside the parenthesis. So the expression (x) has the same value as the expression x, but its classification changes from a variable, which can be passed by reference, to a value, which cannot.)

When we started making changes to the language for Visual Basic .NET, this was one of those minor issues that we decided to clean up. From the constant stream of bug reports and from our own experiences, it was clear that this was something that tripped people up, even experienced developers. We believed that most people wouldn’t have trouble adjusting to the change and it would make VB.NET code less buggy, so the tradeoff seemed to be a good one.

This is, however, the source of one of things I find most annoying about the VB.NET editor. We wanted to help people make the transition from no parenthesis for subroutines, so we added a small "autocorrection" in the editor. If you enter the line

foo bar, baz

in the editor, when you hit Return, we’ll assume you were trying an old-style subroutine call and will pretty list it to:

foo(bar, baz)

This is all well and good, but there are many times in the editor where I end up momentarily creating invalid lines that look like subroutine calls. It drives me nuts that the editor "helpfully" adds parenthesis. Usually, it happens when I’m writing comments and I break off the end of a comment to start a new comment line. Then

' This is a very long comment I would like to break if at all possible, please


' This is a very long comment I would like to break if at
all(possible, please)

if I place the cursor after the word "at" and hit Return. We’re talking about whether this is helping people and whether we can be smarter about when we paste in parenthesis and such.

3 thoughts on “How the subroutine got its parenthesis”

  1. No doubt, VB sub parameter parens have been an issue for many. Seems I mostly correct mistakes in folks’ VBScript, where the developer’s Notepad or VI editor didn’t provide at least a hint by shifting the parenthesized (is that a word?) parameter over one to the right like the VB editor (this was particular tough on folks jumping back and forth between JScript and VBScript in ASP).

    Ultimately, as much as everyone seems to hate it (though I can’t figure out why), we adopted a VB/VBScript standard whereby all subs are executed with the Call statement. That way everything, subs and functions, get parens without fear of inadvertently dereferening sub parameters.

    1. <<Please just take the auto-add-parenthesis thing out of the editor.>>

      Naaa… Just provide an option (as Word does) to individually turn on/off such autocorrections. 😉

Leave a Reply