When to use a tuple

I saw a question the other day from a junior developer who was asking in what scenario you would use a tuple. I figured I would throw my hat into the ring with an answer, simply NEVER USE A TUPLE. I’m aware that that’s not a fair answer, but the thing is if you knew relational algebra you wouldn’t need to ask when to use a tuple, and if you don’t know relational algebra you don’t need to use a tuple.

Let me start off explaining what a tuple is, without explaining relational algebra, it’s just a generic class for storing different types of data. I always find examples easier to follow than abstract descriptions so here’s a simple example of a tuple:

 

var test = new Tuple<int, string>(1, "Testing");

Debug.Assert(test.Item1 is int && test.Item1 == 1);

Debug.Assert(test.Item2 is string && test.Item2 == "Testing");

 

So as you can see, the first type parameter dictates the data type of Item1 and so on for all the parameters. Pretty simple, which is why it can be alluring to junior developers. I’m off and running with a strongly typed object without having to do any of that boring boilerplate code to create a class.  So what’s wrong with that? Have you ever heard the expression “There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors”? One of the hardest things in programming is naming things in such a way as to make it clear what they are. With a tuple you are basically giving up on naming things since everything is called ItemX.

There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors

Why is it so important to name things well? The maintenance programmer, which leads me to another programming quip I love “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”. If you give up on the hardest and most important problem in computer science and just start naming everything Item1, Item2 etc. you have failed as a developer and if I wind up having to maintain your code I may fail to control my inner violent psychopath.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live

So instead of using a tuple, what else can I use? I’m going to go with the most obvious choice because it’s usually the best, a class. Sure you have to type out a definition for your object, but you completely control it so you can do whatever you like with it. This is as simple as it gets and is something no maintenance programmer would ever have trouble understanding.

My second choice would be an anonymous object:

var test2 = new {
    ID = 1, 
    Name = "Testing"
};
 
Debug.Assert(test2.ID is int && test2.ID == 1);
Debug.Assert(test2.Name is string && test2.Name == "Testing");

 

As you can see, it comes out basically the same as a tuple, it’s still immutable (its properties are read only, same as a tuple), it has an arbitrary number of typed properties, but this time you get to set the names. This aids readability immensely.