What’s in a name? Everything!

Finding the right name for your variable, field or function is a task that keeps coming back for everyone involved in software development. I’ve always found this to be a pretty hard task. When I discuss with others about this I’ve often heard people ask: ‘What’s in a name?’. It’s just a name after all.

Whats-in-a-Name-Shakespeare

I’ve always felt like they were wrong; the name is important! very important! But it has been hard to express or even discover why I think it is so important. Recently I’ve been putting together an argument for this and this post is my first attempt at writing it down. I expect edits in the future 🙂

What’s in a name?

Yeah, what is it that is in a name? It’s a philosophical question almost. My name is Stijn. Does that change who I am? I guess it doesn’t. Though I am glad I am not called Alice. 🙂

But let’s keep this discussion focused on names for variables, fields and functions as it applies to software development. I’d like to start by looking at some data (in the form of JSON) and then discuss what it is that is captured in the names that appear in that data:

{
  "name": "George VI",
  "birthyear": 1895,
  "father": {
    "name": "George V",
    "birthyear": 1865,
  }
}

We have an object here with fields `name`, `birthyear` and `father`. There are 3 things to say about each field:

  • It’s name
  • It’s type
  • It’s value

This piece of data actually describes part of the family tree of British monarchs as can be found on Wikipedia, but I think you can see that if we change the values in the name field to say, “iPhone 11” and “iPhone X” and change the name of the ‘birthyear’ field to ‘priceEuro’ and the name of the ‘father’ field to ‘related’, suddenly this describes products in our product catalog.

Same kind of data, but totally different meaning!

Type

The type of data is significant to it’s meaning. Or at least they influence each other; one constrains the other. Going back to the example above, we could change `birthyear` to `priceEuro` because both are numbers. It would have been very hard to change `name` to `priceEuro` because the types of data don’t match. We expect prices to be numbers, or at least be easily converted to numbers. But in the `name` field here, they are not.

Now looking closer at types, we can see that (apart from undefined/null) JSON only distinguishes between 5 different types. 3 primitive types and 2 structured types.

Primitive types (excluding null/undefined)

  • boolean
  • number
  • string

Structured types

  • object
  • array

Now looking at primitive types, I’ll hope you agree that, because there are only 3 of them, they provide very limited meaning to the data. Almost everything is a string. And if it’s not it’s going to be a number or a boolean. And that’s it.

Looking closer at the structured types, an array is a nearly transparent container of whatever you put in it. You have more than one of it. That’s about as much meaning as it adds: there can be more than one. With objects though, we can create a near infinite amount of different ones just by adding or removing fields with different names and types. Objects determine the shape of our data.

My assertion is that this is were meaning is coming from. The shape of our data.

But what is that shape? It’s 3 things:

  • The fields of the object
  • The types of those fields
  • The names of those fields

In the end, when you traverse the JSON as if it was a tree, you will find that all leaf nodes are always primitives. An array can contain objects or primitives, or other arrays, that can contain objects or primitives et cetera but at the end of the line you always end up at primitives. Just like in SQL. Database tables contain columns that are always of primitive types (at least in the pure form of the model). The nested objects we see in the JSON are normalized away in the database and are replaced by a primitive, usually a numeric ID, that references the nested object. So in it’s pure form, the schema of a database is a modeling of named fields with primitive types in different named tables. And we already concluded that the primitives provide only very limited meaning. So (the majority of) the meaning must be coming from the names.

So what am I saying?

I am saying that the vast majority of meaning, that which turns useless data into useful information, is derived from (or modeled as) the names of the fields and types we use in our system. Without these names, our schema turns into a mostly meaningless collection of strings, numbers and booleans.

So what’s in a name?

Everything!

It’s all we have!

What do you think? Is variable naming difficult for you? Do you have a trick for it? Or are you one of those programmers that just name everything a, b, c… Share your views in the comments.

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s