One of the things that programmers do a bazillion times during their career is come up with a name for something. Every variable, every sub-routine, every class, every method, every instance, even the program itself and all its supporting files: they all need names. In some cases the naming is obvious and easy, but in others it’s complicated. You can end up creating a big ball of mud if go about it casually.

So one thing you want to start doing is being intentional about naming things.

There are times when company standards, or even the software situation itself, dictate how things are named to such a degree that it’s a no-brainer for the coder. The intention of such standards is to regularize how things are named, and that’s a good idea even without external standards. A company might always require, for a field containing a person’s first name, using first_name rather than fname or firstname or FirstName or firstName (to name the obvious options).

Some high-level systems need things named a certain way because they process objects automatically based on their names. For example, a customer system designed with Account and Contact tables might require join objects named Account_Contact_# (where “#” is some number). The system finds objects to process by combining various table names and looking for the resulting names.

More commonly there are programming languages that have naming protocols that constrict programmers to certain rules. Prolog variable names begin with an upper-case letter, for example, and Ruby uses case and some symbols ($ and @) to provide meta-type information. A big division between languages is that some are case-sensitive while others are not (int and Int may — or may not — be different names).

Also, most languages have conventions about how things are named. In the absence of other forces pushing you away from common convention, it’s usually a good idea to follow it. If nothing else, it makes your code more readable to other programmers familiar with the language (and, one assumes, the convention).

So these things are some of the external forces affecting how you make up names. There’s usually enough freedom left over that it helps to have a consistent and intentional approach. There are some things to consider, depending on how much you want to follow language conventions (which tend to specify much of this stuff).

Two basic decisions involve how you use the underbar (“_”) and how you use case. Here are some of the possible names we might give a function that returns a list of “keys” sorted by name:

get_keys_sorted_by_name
Get_Keys_Sorted_By_Name
Get_Keys_Sorted_by_Name
GET_KEYS_SORTED_BY_NAME
GetKeysSortedByName
getKeysSortedByName
getkeyssortedbyname
getkeys_sortedbyname

That’s most of the more normal variations. You might think that third one is aberrant (and I’d agree), but I’ve seen it in large third-party products.

Even among all those case and underbar variations, the pattern of words above is consistent, but that pattern is another thing you have to be intentional about.

For example, is the word “get” really necessary? If there’s no matching “put” function, it might be tempting, especially if the nature of the language makes it clear the function does return something.

There is also the option of dropping the word “by”, although “sorted name” is awkward. A way around that is reversal; “name sorted” isn’t quite as bad. One more option is using the word “order”, which has one less character than “sorted” (and “order by name” is right out of SQL).

The point is, there’s quite a can of worms you can open when you start making up names. If you name things depending on your thinking that day, your code won’t be consistent over time. That consistency aids both in trying write error-free code and in debugging the inevitable errors that do sneak in.

One consideration is in how things sort in various listings and tools you might use. Imagine that we have four functions related to file-handling:

open_file
read_file
write_file
close_file

If those names appear on a listing of many names — if that listing is alphabetical (as many are) — the four names above will sort to widely scattered parts of the list. But what if we use these names:

file_open
file_read
file_write
file_close

Now those related names will sort to the same place on the list. They’ll still sort in a somewhat “funny” order logically (‘close” coming before “open”), but we’ll discuss object ordering another time.

For related names, whether it makes sense to use verb-noun or noun-verb depends on the situation and your goals. In the example above, it may be more desirable to have all “read” functions sort to the same place (and likewise all “write” functions, etc.). It all depends.

The key is to be aware of — and intentional about — how you go about the business of naming things.