A foo’s errand

You’ve been there before. You’re reading the documentation of some programming language or a library. There is an example. The example looks like this:

class Foo {
public:
    int m_foo;
}
class Bar: public Foo {
public:
    int m_bar;
}
Bar bar;

This is supposed to be helpful. The generic and completely meaningless “foo” and “bar” (and their less popular sibling “baz”) are the anonymous superstars of the computing community. Sometimes you see their Frankenstein amalgam “foobar.” It’s baffling to think how many papers and tutorials and tests and documentation and presentations use them as their examples.

Given that they are so popular, what’s my gripe with them? Well, it’s that — since their very appeal is that they are generic and meaningless — they are perhaps particularly unhelpful for examples. If you want to learn by example, generally you want a concrete, realistic one. When a child asks you what a dog is, you don’t go to Merriam-Webster and say “it’s a domesticated carnivorous member of the Canidae family.” You show them a real dog, or a picture of dog and say “it goes woof.”

I think this is the right approach even for learning technical topics. When I was in university, I first learned about class inheritance through the “animal” example. A bird is a type of animal, but not all animals are birds. A penguin is a bird, but it cannot fly. These are real, existing relationships in the world that we are familiar with. By leveraging them, the concept of “classes” and “inheritance” becomes much more intuitive. We can use the penguin as a launching point to talk about the intricacies of object-oriented design without getting bogged down in UML diagrams and alphabet soup. Taking the above example, compare it with this:

class Animal {
public:
    int speed;
}
class Bird: public Animal {
public:
    int wing_span;
}
Bird hawk;

Now we can see what inheritance is really about: modeling relationships between classes. Sure, we could have said “Bar inherits from Foo,” but it makes a whole lot more sense to just say “A bird is an animal, so it has a speed.” Even without knowing anything about the Liskov substitution principle, a newcomer can say “what about penguins? They can’t fly!” to which I can say “Silence, we do not talk about penguins in CS 101.”

Even better — when you can — is using software examples. Unless you’re making a game or some sort of wildlife simulator (and hey if you are, more power to you), you will never have a class for birds or animals. Maybe rectangles and shapes, as I’m sure you know those examples too. But even better is things you are likely to use. Video games offer a good source in my opinion. Most people are familiar with them; they have tons of evergreen (always relevant content like weapons or characters) and trendy (Fortnite, Among Us, etc.) examples to entice the 19 year old nodding off in the back; and they are actually implemented with software already.

class Weapon {
public:
    int damage;
}
class FunGun: public Weapon {
public:
    int rounds;
}
FunGun proton_pack;

Between these two — either real-world or software examples — it doesn’t really matter and they each have their trade-offs. Real world examples might be better for beginners while software examples might be better before a homework assignment, but both are at least better than “foobar” and its relatives.