Home Dashboard Directory Help
Search

Get rid of mandatory ByVal display (in VB .NET) by Kyralessa


Status: 

Closed
 as Fixed Help for as Fixed


6
4
Sign in
to vote
Type: Suggestion
ID: 542271
Opened: 3/16/2010 8:45:42 AM
Access Restriction: Public
0
Workaround(s)
view

Description

By this time, it's been many years since .NET came out, and I think there can't be that many programmers left who don't know that pass-by-value is the default in VB .NET. Yet our VB .NET code is still cluttered up with ByVals everywhere we look.

It's worse than a nuisance. It makes it harder to see the ByRefs clearly. Compare this...

Public Sub Method1(ByVal name As String)
Public Sub Method2(ByRef name As String)
Public Sub Method3(ByVal name As String)
Public Sub Method4(ByVal name As String)

...with this:

Public Sub Method1(name As String)
Public Sub Method2(ByRef name As String)
Public Sub Method3(name As String)
Public Sub Method4(name As String)

At this point, repeating ByVal everywhere is just noise. I realize it's too late to do anything about VS 2010, but as you prepare for the next version after that, can you consider making a change so that by default ByVal won't display (but ByRef still will)?
Details
Sign in to post a comment.
Posted by woodywood245 on 7/16/2011 at 2:48 AM
I agree that this is ridiculous. I had forgotten that I'd installed SP1, and have spent the last few weeks wondering why I had to type "ByVal" manually. Yesterday I spent an hour going through all of the VS settings trying to find out what was wrong. Now to find out that Microsoft did it and it's not optional?! That's not cool.

Now every time I'm maintaining old code (like I'm doing right now), I have to remember to attach "ByVal", otherwise my code is inconsistent. Besides, I prefer having explicit declaration of how I'm passing the parameter for each function.

To me this is some attempt to make VB behave more like C#, but it sucks if you've been working in VB for years and you have dozens of projects, all saying "ByVal" in every function and now they're going to be inconsistent unless you do extra work.

This should be optional!
Posted by AbsoluteBob on 5/12/2011 at 10:18 AM
How utterly ridiculous! You have "fixed the issue"?!? Based on one user's suggestion of preference you change the default behavior that affects all other developers? I can appreciate that you want to accomodate developers' preferences, so how about the developers who prefer to have the ByVal explicitly stated for clarity, and therefore liked the original behavior of having it inserted automatically? As BillB1234 states, at the very least this should be a configurable option.
Posted by BillB1234 on 4/13/2011 at 7:56 AM
I discovered this "fix" only after installing VS2010 SP1.

So now we have three argument decorators in projects created pre-SP1 and modified post-SP1: ByVal; ByRef; and (blank). What a disaster!

It seems that the implementation was poorly thought out. There should have been a checkbox for keeping the legacy behavior just as we have for the "Option X" stuff.

Now, to restore consistency, we need a clean-up utility to remove all those ByVals from the legacy code.
Posted by Microsoft on 9/11/2010 at 2:55 PM
Hi Kyralessa,

We regularly evaluate the best ways to get these fixes to customers and at this point in time, we're focused on getting this to you in the next release.

-Sean Laberee
Lead Program Manager, Visual Studio

Posted by Kyralessa on 7/9/2010 at 10:00 PM
Very nice! :) Will it show up in a service pack for VS 2010, or will we have to wait till VS next?
Posted by Microsoft on 6/23/2010 at 10:48 AM
Kyralessa,

We have fixed the issue internally and will include it in the next release.

Thank you,
Michael Hale
Program Manager, Visual Studio
mhale@microsoft.com
Posted by Microsoft on 4/1/2010 at 10:40 AM
Hi,

Thanks very much for taking the time to provide this feedback -- it's certainly a sentiment that we've heard many times! While we didn't change the behavior of ByVal in the Visual Basic pretty-lister in Visual Studio 2010 (it still has the same behavior as VS 2008), we are taking a look at doing this work soon for a future Visual Studio release. We'll report back here as we make progress.

Please feel free to contact me directly at dustinca@microsoft.com if you have additional comments or suggestions.

Kind Regards,
Dustin Campbell
Visual Basic IDE Program Manager
Posted by Microsoft on 3/16/2010 at 7:26 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.