VB.NET Function Return

问题:

In order to return a value from a VB.NET function one can assign a value to the "Functions Name" or use "return value."

I sometimes see these inter-mixed in the same function. Personally, I prefer the return.

My question is, what is the internal difference, if any, between the two?

回答1:

There is probably no difference. IIRC, the compiler generated IL converts them both into Return statements unless there is additional usage of a _returnValue variable.

The readability of the FunctionName assignment is poor in my opinion, and an example of a bad VB6 habit. I prefer the _returnValue (NOT RETVAL) variable method also.

回答2:

The difference is that they DO DIFFERENT THINGS!

'Return value' does 2 things:
1. It sets the function return value at that point 2. It immediately exits the function

No further code in the function executes!

'Functionname = value' does 1 thing: 1. It sets the function return value at that point

Other code in the function continues to execute This enables additional logic to refine or override the function return value

Huge difference folks. Remember it's not all about state, it's also about flow.

回答3:

Let's take a look... Oddly the "functionName =" generates less IL?

Code:

Public Function Test() As String
    Test = "Test"
End Function


Public Function Test2() As String
    Return "Test"
End Function

IL:

.method public static string Test() cil managed
{
    .maxstack 1
    .locals init (
        [0] string Test)
    L_0000: nop 
    L_0001: ldstr "Test"
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: ret 
}

.method public static string Test2() cil managed
{
    .maxstack 1
    .locals init (
        [0] string Test2)
    L_0000: nop 
    L_0001: ldstr "Test"
    L_0006: stloc.0 
    L_0007: br.s L_0009
    L_0009: ldloc.0 
    L_000a: ret 
}

回答4:

Doing the following is only provided for Visual Basic 6.0 developers to easily port code over:

Public Function MyFunction() As String
    MyFunction = "Hello"
End Function

I would definitely not recommend keeping doing it if your project includes anyone who hasn't worked with Visual Basic 6.0, as this syntax will be confusing.

回答5:

99 times out of 100 I'll use "return value".

Every once in a while I'll have a function where the other type not only allows me to save a variable declaration, but do it in a way that actually significantly clarifies the function. Usually this happens when I would want to name the return value the same as the function anyway, and often these are recursive functions; something about that construct lends it to the implicit return variable. However, that scenario is extremely rare. I don't know if I have any functions using implicit return variables at all in my current project.

回答6:

Having read that the Return Value syntax was the One True .NET Way Of Doing Things I thought "OK, we'll do it that way then". Then I wrote a function which I knew, hand on heart KNEW, returned either a value from a Return statement or alternatively an Exception under all circumstances, and still got a compiler warning that the function "doesn't return a value on all paths".

Thankfully I came across the Stack Overflow question How can I make this function not generate a “doesn't return a value on all paths” warning? which explained why; adding a default value assignment to the procedure name at the head of the function prevented the warning in my case as well.

Consequently, even though I'll continue to use the Return Value syntax simply for the sake of syntax consistency, I'll also be assigning a default value to the function name just to prevent the possibility of cluttering up the compile process with bogus warnings.