What is bad practice when using out parameters? [c

Question

Are there any principles to keep in mind when using out parameters? Or can I look at them as just a good way to let a method return multiple values?

What did the language designers have in mind when they were specifying the out parameter?

Edit after some thought:

As i'm thinking about it now, I would be inclined to say that excessive use of out parameters could be indicitive of a code-smell. If a method needs to return instances of more than 1 specific type it implies that the method has more than 1 concern, which is a violation of SRP.

Answer 1

One important caveat to keep in mind is that prior to .NET 3.5 SP1, methods that take or return value types are never inlined. This could have large performance implications for small and frequently called methods, such as those of a vector math library.

This is one of the main reasons why the SlimDX vector math library provides overloads that use out parameters instead of return values; it serves as a potential micro-optimization.

Answer 2

Only the same as return values - ie. be careful of anything the called class will retain and use later. On the whole, I do prefer a wrapper object though; makes the calling code a bit more readable.

Answer 3

Personally, I am not too keen on out parameters beyond the established TryParse convention. I prefer to return an instance of a specific type that encapsulates the different parameters, as it makes the code much easier to read imo.

If you don't want to define specific types for this, you can use the Tuple type in the upcoming .NET framework. Tuples are basically a bunch of values wrapped in a type. They are used a lot in e.g. F#.

Answer 4

I use out parameters when I write static TryParse methods on my classes. Just to keep in sync with the CLR.

Other than that, its probably a better idea to return a class that has what you need on it.

Answer 5

There are two situations where I don't see a problem at all in using out parameters, and these situation most often happen along with one another:

1. When a method has to return more than one value;
2. When used in private methods, specifically in imperative sub-routines with a lower level of abstraction.

Comments on the rationale:

• Sometimes you can have operations that change more than one state, so you might operate in a group of objects belonging to a single process with only one function call (might be more semantically meaningful);
• Since intra-class variables are supposed to have high cohesion, thus high coupling, I believe "it doesn't hurt" to have methods using out parameters. That's exactly the opposite for public functions you expect to find in APIs;
• In C#, out parameters seem to show up a lot in code derived from more procedural APIs ported to OO. Numerical and scientific routines are the best example I can find (alglib, AForge, etc.). This reinforces my idea that it is fine to resort for out for internal implementation details, that can be very procedural depending on the problem domain.

As an example of a semantically "atomic" operation that changes two related but independent variables, here goes some Python code and how I ported it to C# (in a private method):

Python:

p1, p2 = FindClosestPair(p, listOfValues)

C#:

Point3D p1, p2;
FindClosestPair(p, listOfValues, out p1, out p2);

I could not think of a more straightforward way of doing it (but I would love to know possible alternatives).

Answer 6

I generally view out parameters as a "code smell", and will try to refactor to a different approach if I run into them. As someone has already pointed out, commonly the refactoring will be to create a new class that aggregates the values you were going to be returning via out params.