Why are 'out' parameters in .NET a bad idea?

If you care about writing reliable code by embracing immutability and removing side effects, then out parameters are an absolutely terrible idea. It forces you to create mutable variables just to deal with them. (Not that C# supports readonly method-level variables anyway (at least in the version I'm using, 3.5)).

Secondly, they reduce the compositionality of functions by forcing the developer to set up and deal with the variables which receive the out values. This is annoying ceremony. You can't just go and compose expressions using them with anything resembling ease. Therefore code calling these functions quickly turns into a big imperative mess, providing lots of places for bugs to hide.


Out - Parameter are a bad idea in my opinion. They increase the risk of side effects and are hard to debug. The only good solution are function results and here is the problem: For function results, you have to create for every complex result a tuple or a new type. Now it should be fairly easy in c#, with anonymous types and generics.

And by the way: I hate side effects too.


Well, they aren't a bad idea I think. Dictionary<K, V> has a TryGetValue method which is a very good example why out parameters are sometimes a very nice thing to have.

You should not overuse this feature of course, but it's not a bad idea per definition. Especially not in C# where you have to write down the out keyword in function declaration and call which makes it obvious what's going on.


They are a good idea. Because sometimes you just want to return multiple variables from one method, and you don't want to create a "heavy" class structure for this. The wrapping class structure can hide the way the information flows.

I use this to:

  • Return key and IV data in one call
  • Split a person name, into different entities (first-, middle-, lastname)
  • Split the address

Tags:

.Net