The Power of a Name

The name of a variable or function has two distinct perspectives. The first is that a name represents an entity or process. It is the handle by which we refer to that entity. Before we continue, I ask that you do a bit of reading about names, specifically, the power of a name. Start with a google search using “power of a name.”
Here are some links to a few items that stood out for me.
A student essay
book titled “The Power to Name”

The above link references a book about naming. Part of the description on that page gets right to the heart of the matter.

The names we give things colour the ways we perceive them. Those in a position to name hold the power to construct others' perceptions and realities.

Here is a web site specifically concerned with the power of names:
Name Structures
There are many companies devoted to naming products and services.

Fairy tails have long been well aware of the power of a name. An article about Rumpelstiltskin starts out with:

Rumpelstiltskin is a story that can be used as an example for a variety [of] cautions. But perhaps it is not about what we should not do but about the power in a name.

Think of Snow White and the Seven Dwarfs. The purity of Snow White and the characteristics assigned to each dwarf by their particular names.
This could go on for pages. I suspect that more than one doctoral thesis in history or psychology centered about the power of a name.
My first point was that a name is more than just a reference to an entity, it helps us to recognize and provides control over that entity.
My second point is that the name of a program, procedure, or variable is far more than just the handle we use to recognize, remember, and reference it. The names become an integral part of their design and construction. Each name builds (or detracts from) the overall character of the program. A program containing disparate names for its functions and variables is difficult to perceive as a cohesive unit.

Here is an example from a C++ book by an author that has written multiple books.

    // Function to compare two boxes which returns true (1)
    // if the first is greater than the second, and false (0) otherwise
    int Compare(CBox xBox)
      {
      return this->Volume() > xBox.Volume();
      }
The function name says compare. Compare for what? Is the argument box larger or smaller? Is it the same length? Width, Height? Is is the same color? The function name is inadequate for the task. In this case the function is to determine when box is larger. Which brings us to the second error: It returns an int when a boolean is needed. If the function returned -1, 0, or 1 to indicate smaller, same or larger, that would be one thing. Even then it would be better to return an enumeration. Let's improve this.

The function name can make a statement that is true or false:
bool This_Box_Is_Larger( CBox xBox ){...}

The function name can ask a question that is true or false:
bool Is_This_Box_Larger( CBox xBox ){...}

The function can return a pointer to the larger box:
CBox* Larger_Box( CBox xBox ){...}

Since the last example is a function returning a pointer, it is clear that the returned pointer references the larger box.

So here are three quick fixes that make much more sense than the original function name. There are additional ways of expressing the intent of the function. But please, do better than Compare!
Many will say this is picking nits. I strongly disagree. When we spend large amounts of time learning how to code, we are learning coding habits. Book authors should display and encourage good coding habits even when, make that, especially when writing example code.

The Point of this page:

The importance of a name is difficult to overstate. The name of any entity tells us about it, conveys its significance, its use, and gives us control over it. When you hear someone say:

“It’s just a name.”

Please Do not let it go unchallenged. Stand up for the importance of a name.

December 2010