How should I name output variables that are the same as the function?

Question

What are some conventions for naming a variable in cases where the name of the variable ought to be identical to the name of the function? I'm using VB.Net.

I often have this problem when writing functions that either perform some mathematical operation, or generate an object. The return variable is declared inside the function, and values in that variable are set throughout the function.

As an example:

Public Function Sum(arrayOfValues as double()) as double()
 dim outputSum as double(arrayOfValues.GetUpperBound(0))
 For i As Integer = 0 To arrayOfValues .GetUpperBound(0)
 outputSum += v(i)
 Next
 Return outputSum 
End Function

Here outputSum could not be simply called "sum". Since VB.Net is case insensitive, the name would conflict with the name of the method.

Here's another example:

 Public Function IsValid(data As List(Of MyObj)) As Boolean
 Dim retVal As Boolean = True
 For Each d As MyObj In data
 If d.SomeProperty > 42 Then
 retVal = False
 End If
 Next
 Return retVal
 End Function

What name can I use that is clear, but does not add unnecessary noise? In the past I have used just "output", and sometimes "retVal" if the return type is of primitive type.

*I've also seen many coders use arbitrary abbreviations just to get around the compiler (such as "MaximumValue" and "maxVal"). This drives me crazy.

• user949300: I often use "result"
• Ewan: is this Visual Basic?
• candied_orange: I'd call these return variables. Calling them "output variables" make it to easy to confuse them with output parameters
• Bernoulli Lizard: @ user949300 I really like your suggestion of "result". It has the added benefit that if the function name changes, the return variable name doesn't have to be updated to match it.
• Martin Maat: Side note: assigning the return value to a variable named "result" is the way to do it in Pascal. Pascal does not even have a return statement, result is the reserved predefined variable for a function's return value. As a former Delphi programmer this convention stuck in my mind and I still often use it before returning it in C#.

Answer 1

Most frequently, I use the variable result.

Don't create ambiguity in the mind of the next Gentle Reader of your source-code. (Since, too bad for you, you just got smooshed by a bread truck, she can't ask you to clarify.) Try to write source code that is "clear 'at a glance.'" Because sometimes the peoople who will be reading it are in a hurry and under pressure. Try to be nice to them ...

Answer 2

VB is a special child among the .NET family in that it is case insensitive (maddeningly so). So I've felt this pain before.

First of all, a good rule of thumb is to have your methods be named after Verbs and your variables/objects be named after Nouns, that often times resolves the conflict.

However if that isn't the case, then I'd use a combo of underscore and lowercase for your result object inside the method:

Public Function Sum(arrayOfValues As Double()) As Double()
 Dim _sum As Double(arrayOfValues.GetUpperBound(0))
 For i As Integer = 0 To arrayOfValues.GetUpperBound(0)
 _sum += v(i)
 Next
 Return _sum
End Function

• Bernoulli Lizard: Yes, the case insensitivity is indeed what leads to this problem. I don't want to use verbs in most cases; that would result in every function requiring some identical and useless prefix, such as 'calculate' or 'get'. I kind of like the underscore though.
• Robert Harvey: Underscores are widely used to designate class fields; they should not be appropriated for this context.
• Steve: I agree with Robert Harvey, the use of the underscore prefix is definitely not kosher in VB.Net, and conflicts with the established pattern of using underscore prefixes for class-level fields which are the backing fields for properties of the same name.

Answer 3

You could sensibly go at this two ways.

One is to use a consistent prefix, like 'ret' or 'out' - so calling the variable 'out_sum'. I also apply this naming system to out parameters.

The other is to name the variable in question something different - like 'accumulator', or maybe abbreviated to 'cuml_sum' - which is more appropriate to its role as an intermediate variable used in the calculation process.

A possible third alternative - which is available in VB6 and VBA (because of how those languages actually assign return values), but I forget now whether it was carried forward to VB.Net - is to use the function name itself as the accumulator variable.