Best practice of using the “out” keyword in C#

Question

I\'m trying to formalise the usage of the \"out\" keyword in c# for a project I\'m on, particularly with respect to any public methods. I can\'t seem to find any best practi

Answer 1

If your result is more complex than a single value, you should, if possible, create a result object. The reasons I have to say this?

1. The entire result is encapsulated. That is, you have a single package that informs the code of the complete result of CalcSomething. Instead of having external code interpret what the decimal return value means, you can name the properties for your previous return value, Your someOtherNumber value, etc.

2. You can include more complex success indicators. The function call you wrote might throw an exception if end comes before start, but exception throwing is the only way to report errors. Using a result object, you can include a boolean or enumerated "Success" value, with appropriate error reporting.

3. You can delay the execution of the result until you actually examine the "result" field. That is, the execution of any computing needn't be done until you use the values.

Answer 2

One advantage of out is that the compiler will verify that CalcSomething does in fact assign a value to someOtherNumber. It will not verify that the someOtherNumber field of Result has a value.

Answer 3

There are only very few cases where I would use out. One of them is if your method returns two variables that from an OO point of view do not belong into an object together.

If for example, you want to get the most common word in a text string, and the 42nd word in the text, you could compute both in the same method (having to parse the text only once). But for your application, these informations have no relation to each other: You need the most common word for statistical purposes, but you only need the 42nd word because your customer is a geeky Douglas Adams fan.

Yes, that example is very contrived, but I haven't got a better one...

Answer 4

I just had to add that starting from C# 7, the use of the out keyword makes for very readable code in certain instances, when combined with inline variable declaration. While in general you should rather return a (named) tuple, control flow becomes very concise when a method has a boolean outcome, like:

if (int.TryParse(mightBeCount, out var count)
{
    // Successfully parsed count
}

I should also mention, that defining a specific class for those cases where a tuple makes sense, more often than not, is more appropriate. It depends on how many return values there are and what you use them for. I'd say, when more than 3, stick them in a class anyway.