VB.NET Function Return

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.

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 
}

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.

When Tools/Options/Text Editor/All Languages/Code Lens is activated, the Reference Count shows above each Sub, Function, or Property statement.

"Return Value" seems better than "assigning a value to the Functions Name". In the latter case, "Code Lens" produces an inflated Reference Count.

' Code Lens reports "0 references" here for Sub Rosa().
Public Sub Rosa()
    Diagnostics.Debug.WriteLine(Test())
    Diagnostics.Debug.WriteLine(Test2())
End Sub

' Code Lens reports "2 references" here for Function Test().
Public Function Test() As String
    Test = "Test"       ' Code Lens counts this as a reference.
End Function

' Code Lens reports "1 reference" here for Function Test2().
Public Function Test2() As String
    Dim strTest2 as String = "Test"
    Return strTest2     ' Code Lens does NOT count this as a reference.
End Function

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.

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.

its quite handy when working with 3rd party factories(_hsf), you can avoid declaring return variables

Public Function CreateExtremum(iShape As INFITF.Reference, iDir1 As HybridShapeTypeLib.HybridShapeDirection, iSide1 As Integer, iDir2 As HybridShapeTypeLib.HybridShapeDirection, iSide2 As Integer, iDir3 As HybridShapeTypeLib.HybridShapeDirection, iSide3 As Integer) As HybridShapeTypeLib.HybridShapeExtremum
    CreateExtremum = _hsf.AddNewExtremum(iShape, iDir1, iSide1)
    CreateExtremum.Direction2 = iDir2
    CreateExtremum.ExtremumType2 = iSide2
    CreateExtremum.Direction3 = iDir3
    CreateExtremum.ExtremumType3 = iSide3
    CreateExtremum.Compute()
End Function