Shmoop loves taking selfies of ourselves. If we were to give a rough estimate, we'd say that we've taken two billion, four hundred thousand, nine hundred sixty-two. Give or take a couple hundred.

At first it was easy to keep track of our favorites by going through them one-by-one and picking what we wanted, but after that first billion we started having some trouble.

Where was the one from that stellar hair day? How about the one from the day the lighting was just right? Ugh, no, definitely not that one; a good selfie should have a high clear-skin-to-zit ratio.

There's just too much data to go through without having a way of keeping track of the ones we love.

Enter: the variable.

Variables are nothing but names and containers and they can refer to many things: primitive data types, objects, parameters in functions, and even functions themselves.

At its core, all a variable needs is a unique name and a value assigned to it. Different languages might make you add extra information like the type of value (whether primitive, object, or function) or the whether it's supposed to change. But the name and the value are the most important parts.

Depending on where they show up (where they're declared) and what they refer to, they fall into a few different categories.

Primitives

Like the mailbox in an apartment complex, a primitive variable is just a name for a place in the stack (the easiest place to access memory). Depending on the data type, the value will be put in memory space and the variable name's tagged to it. The most important part is that it's right there. The computer doesn't need to pull any special maneuvers to find it: all it needs to do is walk downstairs and grab the mail—erm—data.

Objects and Functions

In the way that a primitive variable is the mailbox in an apartment complex, a variable pointing to an object or function is like a P.O. address. All the variables sit in the same place—the stack—but they point to places all over the computer. It's up to the post office (i.e. the computer) to get your information where it needs to go.

When a variable refers to an object or function (which both live in the harder-to-reach Random Access Memory), it's actually assigned to the object or function's address in RAM. That keeps you from having to keep track of every single address or—even worse—messing it up when you want to change information.

It's pretty great.

Parameters

These variables have a really short lifespan. They're the code equivalent of a fruit fly. They go into a function, sending the variables along, and die as soon as the function ends. A beautiful end to a tragic life.

Generally, if you send a value into a function, you're sending a parameter variable that might or might not be attached to something more permanent.

The inverse of a parameter is a local variable, which appears inside a block (usually a function). They're the other side of a parameter: you send variables in as parameters, and once they're in the function they're local variables. Some languages tell you which variables are local, but many don't. You just have to…see them. They can be any type, but you can't get them once you've left the function.