We've all heard some variation of the quote from Phil Carlton. He said, there's two hard things in programming, cash in validation and naming things, and on the surface this may seem true, but I think there are two things that can help context and time. Context can guide us towards a vocabulary and with a vocabulary, it's really only a matter of time until we land on the perfect name.

and with a vocabulary, it's really only a matter of time until we land on the perfect name. Now, neither of these can be forced. If you force context, you can end up with overly technical names and if you force time, then you're gonna stress about naming, making it feel hard. Now, you've probably heard me say I'm not a big fan of hard programming rules to use another quote you often hear in programming,

of hard programming rules to use another quote you often hear in programming, it depends, but I do think there are a couple rules you can follow to make naming things easier. Let me show them through some simple code samples. Alright, the first is avoid abbreviations. There may have been a point in time where using short variable names mattered from memory, but it doesn't anymore. Don't use abbreviations. It makes the code harder to read.

but it doesn't anymore. Don't use abbreviations. It makes the code harder to read. Instead of using a variable named perm, just call it what it is, permissions. Nearly all IDs are gonna have auto complete, and again, in the age of ai, it's gonna complete even more code for you. Similarly, don't say you when you can say user, just call it what it is. It's gonna make the code infinitely more readable.

just call it what it is. It's gonna make the code infinitely more readable and I guarantee you, between your IDE or ai, you're not gonna be typing that full name very often. Another naming rule is to leverage conventions and we can most readily see this within loops. Take for example the classic for loop. It does use abbreviations, but the most conventional naming used in every example for nearly every programming language is I

but the most conventional naming used in every example for nearly every programming language is I so just follow that convention. As we learned in formatting, it allows the reader to quickly scan the code because they can leverage those conventions. The same goes for a foreach loop. The most common convention here is that the collection is plural and the loop variable is its singular form.

that the collection is plural and the loop variable is its singular form. In this case, instead of saying I, we say item, the next naming rule is to leverage context. The most common infraction of this rule is by adding type information to the name. This doesn't leverage the surrounding context. For example, it's very easy to see on the other side of this assignment statement that this variable contains a string.

of this assignment statement that this variable contains a string. We know its type for those reasons you don't need to add type information when naming. This isn't just for variables, it's also for methods. php has a native method called strtoupper and we're all familiar with this method, but its name could be better simply by leveraging the context. We know it to be a string method.

by leveraging the context. We know it to be a string method. Dropping the type information already improves the name and following some of our other rules, we could expand it to not have an abbreviation, so two uppercase. In the end, we've only increased this function name by one character, but this name is infinitely better by leveraging the context and avoiding abbreviations. Let's look at a few more examples of leveraging contexts.

and avoiding abbreviations. Let's look at a few more examples of leveraging contexts. Consider this JSON data structure of components and inside components we have a component property and the number of methods. We have the opportunity to use a much better name for the child component. Leveraging the context, we already know it's a component. What is this really trying to relay? Maybe it's trying to relay its type.

What is this really trying to relay? Maybe it's trying to relay its type. Again, by leveraging the existing context, we free ourselves up to think of a better name. Finally, let's consider some database design. Some old school conventions might have you repeat the database name for each one of its columns. Again, this doesn't leverage the context. I'd go so far as to say it's a waste of characters. By removing the prefix, we not only simplify the name,

I'd go so far as to say it's a waste of characters. By removing the prefix, we not only simplify the name, but we avoid all that extra reading. Now these rules will guide us towards better naming, but they don't actually tell us how to name things better. To do that, we need to fall back on the goal of all of these practices and that is to make the code more human readable and we do the same for this practice. That is to make the name better, we need

and we do the same for this practice. That is to make the name better, we need to make it more human. Let's work through a closing example. Imagine a class called EventManager and it has two methods, handle and remove. Let's first go through this and apply some of the rules that we've learned. First, I'm seeing some abbreviations, so let's make these their full name.

First, I'm seeing some abbreviations, so let's make these their full name. In this case, we'll say event and instead of funk, we'll call this function. Now our next rule would be leveraging conventions. Right now we don't necessarily know what this eventManager does. However, looking at the names of the methods I see handle and I see remove. These don't really line up or set another way.

and I see remove. These don't really line up or set another way. They're not very symmetrical and we will talk about that in a future practice, but for now, conventionally, I feel like if you have a remove method, you should probably have an add method, so I'm gonna rename handle. To add, the final rule was leveraging context. Now, right away I feel like eventManager

To add, the final rule was leveraging context. Now, right away I feel like EventManager doesn't leverage context. I said before that when we force context, we come up with overly technical names. Anything manager definitely feels like an overly technical name to me. Looking at the other context, we seem to add an Event. Even the name Event here is repeated, given the surrounding context.

Even the name event here is repeated, given the surrounding context. I feel like this could be called listener. We're adding and removing event listeners and if that's the case, then conventionally, instead of passing in a function here, we might be more used to seeing something like a callback just by working through the three naming rules we've outlined. This is already better, but I'd argue we could take it a step farther.

This is already better, but I'd argue we could take it a step farther. We could make it more human. It's still a bit technical with its adding and removing of event listeners, what is this code really to answer that, we'd have to go a bit higher up and know what the system does. So let's say this was a telephony system, maybe one that connects calls. Given that context, we could now build a vocabulary, one

that connects calls. Given that context, we could now build a vocabulary, one that we could use to refine this code and make it even more human readable. So instead of listener, we might call this an operator. Now, does an operator add and remove? That's not really part of the vocabulary. Instead, an operator might connect and disconnect taking it even farther. Are they connecting and disconnecting

and disconnect taking it even farther. Are they connecting and disconnecting events within this system? No. They're connecting calls and instead of connecting a call to a callback, they might connect it to an endpoint. We see that once we identify the human context of code and land on a vocabulary, how easy it is to start naming things. Now, making that leap might feel a little bit hard.

to start naming things. Now, making that leap might feel a little bit hard. That's where time comes in. Pay attention when you're describing features of your application. Pay attention when you're talking to clients, what words are being used over time. You should be able to build a context if you still can't find the right name. From that context, break out of the source,

if you still can't find the right name. From that context, break out of the source, start finding words, and even if it's not the perfect one, use it anyway. Don't stress, keep naming things easier, keep writing code, and that perfect name will reveal itself in time.