About half of code examples include the term ‘foo,’ here’s what it means and why you should never use it in your examples.
Here is what ‘foo’ means:
‘Foo’ doesn’t mean anything, it’s just a commonly used example name for a variable.
Very often in programming we need to name a variable something. A variable is a container for some value, and to be useful that variable should have a name that helps make code readable. In real code I might have a variable like user_heightto let me easily refer to that value inside my code.
Variable names are where foocomes up. Sometimes we need to refer to a variable without knowing even what we should name it. Let’s say we want to describe a function and say, in english: “this takes whatever variable you give it and prints it out twice” our variable might be called user_height, it might be called user_first_name, it might be called user_updated_legacy_variable_setting_LOCKED_v2_updated_index! We just want to say that _whatever _variable you give it, this will print it twice, in many examples, foo is used as an example variable name.
If we were in math class, we’d call this variable ‘x’, and say “this function works like this: print X, then print X”. And we’d immediately understand that it doesn’t matter what X is, we wouldn’t raise our hand and ask “Does this function work if instead of X my variable is named Q?” Yes it works! It doesn’t matter what we name our variables.
Here’s why you should never ever use ‘foo’
Let’s take a step back and assume you didn’t just read a definition of foo. Let me show you why it’s really not a great idea to use in your examples.
Programming is surprisingly general. Most programming languages look kind of similar to each other. Why, look at this snippet of C, a language I do not know:
#include <stdio.h>
int main() {
const char *foo = "Hello";
const char *bar = "World!";
fprintf(stdout, "%s %s\n", foo, bar);
return 0;
}
That looks pretty readable! I can figure out what most of it is doing. Heck let’s step through it!
#include <stdio.h>
Okay we’re probably bringing in required packages with include, the name of the package is, studio? Oh no, Standard Input/Output > Standard I/O > stdio, got it.
int main() {
Definitely defining a function, probably ‘main’ is a function that gets run by default. Gonna cheat a little here and lean on my knowledge that types are something the C languages care about (at least they care about it more than Javascript), so I bet that int means this function returns an integer, and that ‘return 0’ seems to indicate I’m right.
const char *foo = "Hello";
Declaring a constant, it’s a ‘char’ type which probably means it’s a ‘character’ type. Doesn’t C have strings? Whatever. I can see it getting set to “Hello” so char must be how strings are stored. Whyfoo though?
const char *bar = "World!";
Why *bar?
fprintf(stdout, "%s %s\n", foo, bar);
Fprintf is a weird way to print, but yeah, it’ll go to ‘standard out’ which usually means the console in my experience. And it prints some special characters, looks like space ‘%s’ and a newline ‘\n’, and then foo and bar
return 0;
Gotta return something, and my guess is it’s gotta be an integer.
}
Okay I defined everything but foo and bar, I’m sure we can work that out, let’s check the C Reference Manual to get a definition of ‘foo’
…
…….
Huh.
‘Foo’ appears 70+ times in the C Reference manual, but the closest I get to a definition is:
“Lowercase letters and uppercase letters are distinct, such that foo and FOO are two different identifiers.”
And that’s it? What the heck is foo?
Again, both ‘foo’ and ‘bar’ are by definition meaningless nonsense words, used to mean ‘any random label could be on this variable, method, whatever, I chose this to show that nonsense would work.
The use of ‘foo’ in code examples dates back to the 1960’s, and it’s bad. The use of foo as ‘a name that means nothing’ makes your code more difficult to interpret and use for the student.
We have a responsibility to make our work accessible. To make it readable and useful. When we write code to use in production, both the code itself and the accompanying documents must be easy for others to understand, because unreadable code is almost useless.
Does it save time to write only for experienced people? Sure. I write about Heroku all the time and I’m tempted to just say ‘Heroku CLI’ instead of ‘Command Line Interface’ but the use of a whole bunch of acronyms makes my writing much harder to understand.
Foo is a barrier to people understanding your examples, and while all code should be easy to understand your examples should be the easiest part to read!
How to avoid using ‘foo’
Use ‘CLI,’ ‘npm’ and ‘TDD’ enough in your article, and you’ll ensure that you saved 10 minutes writing your article, and made something that no new developers can understand. It takes a few extra letters to type out every initialism (like ‘TDD’), and when the benefit is accessibility it’s worth it. The same is true of ‘foo’ let’s fix this example:
#include <stdio.h>
int main() {
/* of course, these variable names can be whatever you like */
const char *first_word = "Hello";
const char *second_word = "World!";
fprintf(stdout, "%s %s\n", first_word, second_word);
return 0;
}
Let’s do another, this time replacing ‘foo’ and ‘bar’ in a random number generator
#include <stdio.h>
#include <stdlib.h>
int main() {
int count, randomNumber;
printf("Ten random numbers in [1,100]\n");
for (count = 1; count <= 10; count++) {
randomNumber = rand() % 100 + 1;
printf("%d\n", randomNumber);
}
return 0;
}
And that’s it! We’re done. A comment and a rename. And get this: we could redo every example in the C Manual in a few hours.
The result is code that is more readable on every line.
The key points to consider:
- Does it matter that a variable could be named anything?
- Could a comment help a new programmer here?
- Could variable names better describe what’s happening here?
We write to be understood
We all have a responsibility to write information that can be understood. Communication is not a solo project. The next time you set down to write examples to help others, take a moment to consider that someone reading this might well be in their first year of coding. This student is googling to find solutions and when they find ones they can read they’ll feel inspired, energized, and empowered. You can give them that feeling by using meaningful variable names.
Top comments (21)
This mindset is one of the big reasons I listen to what Wes Bos has to say on his podcast and in his video courses. (syntax.fm and wesbos.io if you've never seen). Getting rid of as many confusion points for people not "in the know" is vital, thanks for writing this!
I love Wes Bos so much. I’m a much better tech writer for closely following his work. Anyone who read and enjoyed this should definitely check him out!
Just added Syntax. to my podcast list. Thanks for the inadvertant recommendation!
I say using
foo/baris a missed opportunity to add context which would make the example much easier to understand.It is also a missed opportunity to show good naming while explaining something.
Don't miss these precious opportunities.
It seems that 'x' in math sounds much more familiar to us than 'foo' and 'bar' in programming because we are old enough to not remember the first time we saw 'x' in an equation back there in primary school, but it was the same feeling. Straining my memory I can remember that the teacher actually had to explain that 'x' is just a way to say the value is unknown and can be any letter you want. So, I agree that in some cases it may have better names, but it is not something we must stop using altogether, it makes part of the programming world and it is a knowledge that you acquire pretty quickly and you will remember for the rest of your life, like 'x' in math.
Thank you for this. So many times I've found docs with
fooetc and my brain just kind of tunes out then. With no meaning, I have a hard time understanding the purpose of the code. In the last couple years I've been aiming to give purpose to any example code -- to give some context beyond just learning a concept.There are two paragraphs in your piece which provide the meat of your argument - but you bury them. Those paragraphs are
and
The question that I don't believe you really answered is "why is Foo a barrier to understanding?". I answer that question as follows:
As a long-time C programmer I found your walkthrough of the example function annoying - it is my opinion that if you are going to provide an example you should use a language where you can make that point with ease. Freely admitting that you don't know C is fine - but please do not then use an example written in that language. [I'm more than happy to write a different discussion of that function if you'd like - DM me].
I personally feels like it works better because it is a language he isn't too familiar with.
Because most of the people looking at examples with
fooandbarare the ones who are just getting into the language, and speaking from experience having examples there really does harm readability and some function/variable names would have been better off if they were given a more specific name instead.Some people were probably fine reading through
foo/barexamples, but that doesn't negate the fact that a good chunk of people out there would rather have sensible naming for examples so that they can visualize the code they're trying to learn betterThe thing is, if I am doing code review or telling someone they are not following Single Responsibility Principle by throwing everything in main, I will tell them to:
def foo():
bar0 = process0()
...
barN = processN()
baz = doing_stuff(bar0, ..., barN)
return baz
Foo bar baz is a specific way to show theory, principles, and has it's place. Much like the comment below . and
xin math.I found it a bit weird that the author does have the knowledge to dissect a program in a language she does not understand, but lacks the knowledge that foo and bar are non-meaning variables.
She does have a point though, that 'foo' and 'bar' are 100% meaningless and could easily be replaced with names that do make sense.
I never tell people the compiler doesn't care about meaningful variable names and that they're just for humans.
I tell people that if they use meaningless names, compiler will judge them silently.
Brilliant! 😁😁😁 I hope you don't mind me copying that.
I do agree that caring for naming things right is very important, but, sometimes, specially in testing, you need a "wildcard" variable, an example, something that doesn't matter per se, that's when "foo" come into play.
Great article ! 100% agree on this
In my first job as a programmer I had to debug a COBOL program someone else had written. At seemingly random times a running total would get wiped out. It turns out the programmer learned assembler first and kept naming his variables V01, V02, ... even though he could have used longer names. The whole program was written that way. I had to create a cheat list and go through every single one till I figured out he was reusing one of them in an unrelated block.
Foo and bar comes from 'fubar'. Here is what Wikipedia says about it (censored by me):
FUBAR is a military acronym for "f*** up beyond all recognition" (or, expurgated, fouled up). Alternatively "...beyond all repair", or "...beyond all reason").
Tbh that's often the status of my code, so I'll keep using it lol