‘Stupid’ Question 17: Is use of Tuple, Anonymous Type and/or Out parameters a code smell?

In some cases I prefeer a tuple as a return value and I dont consider it an code smell.  An example is an computed coordinate. 

Out is definitely a code smell, it's a good indicator that the method isn't side-effect free. 

One important feature of Tuple and anonymous types is that that implement all the equality-stuff; Equals, GetHashCode. Tuple also implement IComparable (not sure if anonymous types do that). That can be very important if you use Linq. 

So if you ie want a multi-valued key for a Dictionary, Tuple is the way to go. 

One reason that we started avoiding out parameters is that once you start using async (Task) methods, out is forbidden by the API.   As moving toward using async methods seems to be a good thing for performance reasons in a number of cases, it seems that avoiding any API decisions that prevent the easier adoption of the async is a good thing. 

I don't use tuple ever, rarely use the out keyword and use anonymous types often.

In the example of returning co-ordinates; this may be ok for the person writing the code but how would anybody else consuming this code be able to make sense of the data? if it were me I would create a class to hold the information with meaningful properties, which ok takes a little longer to develop but is easier to read and understand by other developers.

A good coding habit to adopt is to write code that is descriptive and easy to read and understand.  Method names, property names, variable names - it all matters! it's better to have descriptive names than to have a 200 word summay in comments, which will never be maintained.

As for anonymous types they are great to use but avoid them as a return type and don't expose them through the interface, generally other consumers won't understand the structure of the object and will have to read into the implementation to figure out how to use it etc.  They do have their uses though, especially with LINQ and returning new types using the Select extension method.

In alot of cases I see the var keyword and anonymous types mis-used in favour of lazy programming.  Just because something works does it mean it's implemented the "right way"!.  This is my opinion anyway. 

Now, are we talking about the use of these in general, or as return types?

"out" can only be used to return a value.  I'd say one out parameter is ignoreable. Two or more would make me investigate the method.

On the other hand, anonymous types CANNOT be used as a return value.  I wouldn't consider it a code-smell, since I've rarely if ever seen one abused. I imagine they could be abused, but it would have to be near 50% of the time before it rises to the level of "code smell"

Tuples are harder to categorize.  They aren't like "out" parameters where any use is iffy, and it's just a matter of degree.  Sometimes Tuples are perfect appropriate, others they're being abused.   I'd case I'd have to phrase it as "If the code is hard to read/understand because of the use of a tuple, that's a code-smell" 

Mattias: But a computed coordinate should have an "X" and a "Y", and should be used as both input and output to many method.  In which case, it should have it's own class.

Brad:  We can debate whether or not "out" is a code-smell (see my previous comment), but I can see no connection between using an "out" parameter and having side-effects.  TryParse() is the most famous "out" user and it has no side-effects. (and the most famous method WITH side-effects, Console.Write() has not "out" parameters) 

Even for things like T.TryParse(...), an out parameter is not really needed.  The .NET team could easily have introduced something like ParseResult, an immutable struct that has a boolean indicating success/failure, and something of type T to indicate the parsed value.  Of course the out overload would have to remain to support pre-generic code. 

@Eric: But then you couldn't use it in an if() statement.    So, instead of 

     Int x;
     if (Int32.TryParse(str, out x)) ....

we'd have 
     var result = Int32.TryParse(str);
     if (result.Success) ....

on the whole, it's pretty much a wash. 

I think debates like these have merit but should be kept in context. There are situations where these languages constructs are useful, but there should be a clear justification in their use. If they are sprinkled everywhere throughout your code, then there is a definite problem. 

I steer clear of tuples in C# because the language support for them is horrible compared to the elegant way they are done in languages like Python. Would be lovely to be able to write something like:

var (success,result) = int.TryParse("Hello World")

I tend to use lightweight classes instead. Automatic properties has at least made the definitions of those classes more concise.