FooBar is FooBad
FooBar is a metasyntactic variable. A “specific word or set of words identified as a placeholder in computer science”, per wikipedia. It’s most abstract stand-in imaginable, the formless platonic ideal of a Programming Thing. It can morph into a variable, method or class with the barest change of capitalization and spacing. Like “widget”, it’s a catch-all generic term that lets you ignore the specifics and focus on the process.
And it’s overused.
Concrete > Abstract
Human brains were built to deal with real things. We can deal with unreal things, but it takes a little bit of brainpower. And when learning a new language or tool, brainpower is in scarce supply. Too often, `FooBar` is used in tutorials when almost anything else would be better.
Say I’d like to teach Python inheritance to a new learner.
# Inheritance
class Foo
def baz(self)
print("FooBaz!")
class Bar(Foo)
def baz(self)
print("BarBaz!")
A novice learner will have no idea what the above code is doing. Is it `Bar` inheriting from `Foo` or vice versa? If it seems obvious to you that’s because you already understand the code! It makes sense because we already know how it works. Classic curse of knowledge. Why force learners to keep track of where Foo comes before Bar instead of focusing on the actual lesson?
Compare that to this example using concrete, real-world, non-abstract placeholders
# Inheritance
class Animal
def speak(self)
print("")
class Dog(Animal)
def speak(self)
print("Bark!")
This is trite and reductive. But it works. It’s immediately clear which way the inheritance runs. Your brain leverages its considerable real-world knowledge to provide context instead of mentally juggling meaningless placeholder words. As a bonus, you effortlessly see that the Cat class is a noun/thing and the speak() method is verb/action.
Concrete Is Better for Memory
Even if a learner parses your tutorial, will they remember it? The brain remembers concrete words better than abstract ones. Imagine a cherry pie, hot steaming, with a scoop of ice cream melting down the side. Can you see it?
Now try to imagine a “Foo”… Can you see it?
Yeah, me neither.
Concrete examples are also more unique. AnimalDog is more salient than FooBar in the same way “John is a baker” is easier to remember than someone’s name is “John Baker”. It’s called the Baker-Baker Effect. Your brain is full of empty interchangeable labels like Foo, Bar, John Smith. But something with relationships, with dynamics and semantic meaning? That stands out.
Concrete Is Extensible
Lets add more examples to our tutorial.
Sticking to Foo, I suppose I could dig into the Metasyntactic variable wikipedia page and use foobar, foo, bar, baz, qux, quux, corge, grault, garply, waldo, fred, plugh, xyzzy and thud.
# Inheritance
class Foo
def qux(self)
print("FooQux!")
class Bar(Foo)
def qux(self)
print("BarQux!")
class Baz(Foo)
def qux(self)
print("BazQux!")
But by then, we’ve strayed from ‘beginner demo’ to ‘occult lore’. And the code is harder to understand than before!
Using a concrete example on the other hand…
# Inheritance
class Animal
def speak(self)
print("")
class Dog(Animal)
def speak(self)
print("Bark!")
class Cat(Animal)
def speak(self)
print("Meow!")
Extension is easy and the lesson is reinforced rather than muddied.
Exercise for the reader See if you can rewrite these python examples on multiple inheritance in a non-foobar’d way.
Better Than Foo
Fortunately, there are alternatives out there. The classic intro Animal, or Vehicle and their attending subclasses. Or might I suggest using Python’s convention of spam, eggs, and hams? A five-year old could intuit what eggs = 3 means.
There’s also cryptography’s Alice and Bob and co. Not only are they people (concrete), but there’s an ordinal mapping in the alphabetization of their names. As an added bonus, the name/role alliteration aids in recall. (Mallory is a malicious attacker. Trudy is an intruder)
New Proposal Pies
Personally, I think Pies make excellent example variables. They’re concrete, have categories (Sweet, Savory), subtypes (Fruit, Berry, Meat, Cream) and edge cases (Pizza Pies, Mud Pies).
# Pies
fruit = ['cherry', 'apple', 'fig', 'jam']
meat = ['pork', 'ham', 'chicken', 'shepherd']
nut = ['pecan', 'walnut']
pizza = ['cheese', 'pepperoni', 'hawaiian']
other = ['mud']
They also come baked-in with a variety of easy-to-grasp methods and attributes like slice(), bake(), bake_time or price. All of which can be implicitly understood.
Though if pies aren’t your thing, there’s a whole world of concrete things to choose from.
Maybe breads?
['bun', 'roll', 'bagel', 'scone', 'muffin', 'pita', 'naan']
Conclusion
I’m not holding my breath for foobar to be abolished. It is short, easy, abstract, and (most importantly) established.
Mentally mapping concrete concepts is hard. Analogies are tricky and full of false assumptions. Maps are not the territory. You’re trying to collapse life in all its complexity to something recognizable but not overly reductive or inaccurate. But the solution is not to confuse abstractness for clarity.
For tutorials, extended docs and beginner audiences, skip foobar. Use concrete concepts instead, preferably something distinct that can be mapped onto the problem space. And if it gives implicit hierarchy, relationships, or noun/verb hinting, so much the better.
Use FooBar when you’re trying to focus on the pure abstract case without extra assumptions cluttering the syntax. Use it in your console, debuggers, and when you’re talking to experienced programmers.
But for anything longer than a brief snippet, avoid it.
The post FooBar is FooBad appeared first on Simple Thread.
+1 888-688-2939 
