tags:

views:

52

answers:

2

Why must the line continuation character (_) be the last one on the line? Is there a technical reason for this or is this a usual Microsoft "feature"?

In other basic dialects you can add a comment after it, but not in VB.net, so I'm curious as to why Microsoft decided to not allow comments on these lines.

+3  A: 

One of the developers who works on Microsoft VB.Net has a blog post about this idea. He says it's a nice idea but requires some compiler refactoring.

If you think it should be prioritised, you could leave a comment on the blog. Or suggest something at Microsoft Connect.

MarkJ
Well that sort of answers it. The blog post says: "However, the current compiler architecture dates back from the days that VB was strictly line-oriented language so we’d have to refactor the compiler first" which is another way of saying that Microsoft hasn't updated the parser in a decade...
To be fair, I'd be the first to complain if they were updating their parser for fun, rather than implementing useful new features in VB. BTW I think comments after line continuations would be useful, but I probably wouldn't pick them as a very high priority.
MarkJ
+2  A: 

It has to be baked into the compiler, because the disassembled code looks no different. Take a look at the following code:

    Dim nameVar As String = "John"
       MsgBox("Hello " & nameVar & _
              ". How are you?")

MSIL looks at it like this:

IL_0000: nop
IL_0001: ldstr "John"
IL_0006: stloc.1
IL_0007: ldstr "Hello "
IL_000c: ldloc.1
IL_000d: ldstr ". How are you\?"
IL_0012: call string [mscorlib]System.String::Concat(string,
string,
string)

Now the same code without line continuation:

        Dim nameVar As String = "John"
        MsgBox("Hello " & nameVar & ". How are you?")

MSIL is identical:

IL_0000: nop
IL_0001: ldstr "John"
IL_0006: stloc.1
IL_0007: ldstr "Hello "
IL_000c: ldloc.1
IL_000d: ldstr ". How are you\?"
IL_0012: call string [mscorlib]System.String::Concat(string,
string,
string)

So this is a "feature" of the compiler. Why do it this way? When explaining anything about VB.NET, you need to look back to classic Visual Basic. Many of the principals and procedures were simply just Grandfathered to VB.NET for a comfort level and to attract VB6 and earlier programmers. So why it is the way in VB.NET (2008 and before) is probably because it was that way in VB6 and earlier. And I would venture to guess it was done that way in VB6 because of IDE limitations prior to compiling the code, but we can never know that unless somebody from the original VB6 Microsoft team added thier reasoning behind it.

Hope this helps!

atconway
Thanks for the thorough answer!