Foobar names

foobar is a term one often encounters when searching the web for tutorials on programming. What it is supposed to mean is not really clear; some people, though, claim that it stems from the German word furchtbar, which translates as horrible. I am no authority on etymology, but whenever I see a tutorial using foo and bar as variable names, I think furchtbar is quite fitting.

What is the purpose of a name? A name is a representation of a concept, an object, or an action. When I think of the name table, I also think leg, surface, and board games. When I think of the name run, I think of speed, movement, destination, and that I should do it more often.

When I think of foo and bar, I think of nothing at all. Instead, I have to analyze the present situation, find out what both names represent, and hope that I do not forget their meanings in the future. The point I would like to make here is rather obvious: Use meaningful names for your functions, classes, members, variables, packages, etc.

Names for abstract situations

When you post a question or an answer in some online forum, you often have abstract situations. When it comes to questions regarding inheritance, for example, you often find this:

class foo {
	// methods and members
};

class bar : public foo {
	// methods and members
}

It is better to use names which focus more on the area of your question, i.e., inheritance:

class Base {
	// methods and members
};

class Derived : public Base {
	// methods and members
}

When you explain your problem in more detail, being able to refer to Base and Derived will help readers to understand your question or answer more easily.

Names for functions and classes

Good function names usually consist of a verb and potentially an object. For example, a factory function (a function which returns a newly created object of some type) for table objects should be called make_table() or create_table(). Function names which return a boolean value often start with is or has. For example, is_male() or has_personal_problems() might be good names for members of a Person class.

Classes are typically named after nouns. A factory class for furniture could be called furniture_factory and could possess a method called make(). An important exception are classes which are intended to be used in a function-like style. These functor classes overload operator(). For example, a functor class for the multiplication of two numbers could have the following declaration:

class multiply {
public:
	multiply(double multiply_by) : 
		constant_factor_(multiply_by)
	{
	}

	double operator()(double factor) const
	{
		return factor * constant_factor;
	}

private:
	double constant_factor_;
};

Names for instances and parameters

Just like functions and classes, instances, variables, constants, parameters, and arguments should have a meaning, too. For example, when writing a test you usually compare two values of the same type with each other. Do not call these values v1 and v2. Call them expected and actual instead. When you compose text and variables with an instance of std::ostringstream, call it message if it is meant to be one. When you provide a function for reading XML content from a file, do not call the input file stream parameter f. xml_file seems like a better name.

Abbreviated names

Abbreviations can save time and make code more readable. On the other hand, abbreviations can also make code illegible. Reasons for using an abbreviation include the following:

• The abbreviation is an integral part of the ubiquitous domain language. If you write software for handling value added tax, then VAT is a legitimate abbreviation. Likewise, established data structures like last recently used caches can be safely abbreviated to LRU_cache.
• The abbreviation is already established by the standard library. For example, C and CT might be acceptable names for template parameters of classes which handle characters in some way. Char and Char_Traits might still be a better compromise between readability (C) and clarity (Character).
• For variables it might be okay if it is only used in a very limited scope. i is alright when used as a counter in a loop, provided the loop body is limited to just a few (approximately three) lines.
• For mathematical algorithms it is often useful to stick to the name convention of the paper in which the algorithm is described. A comment in your code should point future readers to the reference.
• The abbreviation is really obvious. config should be fine to represent a configuration, whereas con is too short.

Bad names hint at bad design

Take some time to think about a good name for whatever it is you are currently coding. Being unable to find one is often a hint for bad design. Think of a function called wash_and_dry(). I once had a washing machine which claimed to do both. I assume you would not be surprised if I told you it was not good at either task. The same may go for your function. The name indicates that your function tries to accomplish two things. There might be two functions lurking inside. Think of finding a better name as an opportunity to improve your design.

Conclusion

There is still much to say about good names. The key lesson, however, is this: Choose your names wisely. A name should clearly communicate what it represents, be it an object or an action. Good names help readers to understand what your code is supposed to do. In some cases the need for finding good names can even trigger refactorings towards cleaner code.