Are "out" parameters a bad thing in .NET?

Question

Are "out" parameters a bad thing in .NET? Any good articles/discussions on this topic?

Answer 1

For most circumstances I would recommend against using Out parameters. They basically add side-effects to your code and could be a nightmare when it comes to debugging.

There's an article on MSDN regarding Out parameters available here: http://msdn.microsoft.com/en-us/library/t3c3bfhx.aspx

Answer 2

I think they are really useful when needed.

An Msdn article for both ref and out parameters.

Answer 3

Well, I have an article on what ref/out do - but it doesn't discuss whether or not you should use them.

Basically out parameters are usually a sign that you want to effectively return two results from a method. That's usually a code smell - but there are some cases (most notably with the TryXXX pattern) where you genuinely want to return two pieces of information for good reasons and it doesn't make much sense to encapsulate them together.

In other words, avoid out/ref where you can do so easily, but don't go massively out of your way to avoid them.

Answer 4

Good question. My answer is that I don't particularly like them, but I do use them in one of my projects where multiple return values are common. I have a financial data library that returns the actual price (or null/zero), a major error code, and a minor error code. The library has dozens to hundreds of methods, and each error code is a different type, so creating custom classes for each one and returning an instance of that would be very unwieldy.

Answer 5

This question has a good discussion:

http://stackoverflow.com/questions/214688/why-does-the-net-framework-guidelines-recommend-that-you-dont-use-refout-argume

Answer 6

FxCop doesn't think it's a good idea...

http://msdn.microsoft.com/en-us/library/ms182146(VS.80).aspx

Answer 7

Out parameters are useful when you need to return more than one object as a result of a function. To my eyes,

void doSomeThing(Thing toDoItTo,
                 out OtherThing result1,
                 out AnotherThing result2)
{
    ...
}

OtherThing y;
AnotherThing z;

doSomeThing(x, out y, out z);

y.method1();
z.method2();

is a lot cleaner than

struct DoSomeThingResults
{
    public OtherThing Result1;
    public OtherThing Result2;
}

DoSomeThingResults doSomeThing(Thing toDoItTo)
{
    ...
}

DoSomethingResults results = doSomeThing(x);

results.Result1.method1();
results.Result2.method2();

and additionally, using out parameters means that the results are guaranteed to be assigned.

Answer 8

In the absence of tuples, they're sometimes the cleanest way to do things. I generally hate them, though.

F# has some nice syntactical sugar for dealing with them. Rather than making me deal with out parameters, it treats them as methods that return tuples instead. The various TryParse methods end up returning two element tuples:

let success, value = Int32.TryParse("1234")
(* success is true *)
(* value is 1234 *)

It's quite handy, and doesn't make me feel dirty.