Skip to content
loading...

Against 'foo' (and 'bar' too)

Nočnica Fee on June 10, 2019

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 ‘... [Read Full]
markdown guide
 

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/bar is 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.

 

There are two paragraphs in your piece which provide the meat of your argument - but you bury them. Those paragraphs are

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.

and

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!

The question that I don't believe you really answered is "why is Foo a barrier to understanding?". I answer that question as follows:

Variables used in example functions should relate directly to those
functions. Since "Foo" is a made-up word, it *cannot* relate to
anything in those functions, which works against the point of the
example.

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 foo and bar are 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/bar examples, 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 better

 

The 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 x in 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.

 

Thank you for this. So many times I've found docs with foo etc 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.

 

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.

 
 

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

 

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.

 

I never use foo/bar/baz/qux as variable names, but I do often use them in tests as string values. Used with descriptive variable names, I feel this is ok.

 

I think using Foo/Bar in API documentation is a very good sign that your example code is not properly communicating what it is supposed to be doing. That being said, I think using silly nonsense words in tutorials can have a good purpose. In certain cases where someone is learning a new language it might be useful to show them how to initialize variables in that language compared to other languages. Basically any sort of lesson on the actual concept of variables can and probably should use some silly nonsense word to show that people can name their variables anything they want. While most programmers know that variable names don't matter to the compiler interpreter, someone going into programming for the very first time might not fully understand that and long, specific variable names might add confusion to the lesson. This obviously depends on the student AND the teacher but I remember being confused by misunderstandings that just seem silly now when I started learning to program.

(Also Foo and Bar are a part of programming culture and it is our duty to teach newer programmers about them. ;P)

 
 

I like using foo and bar in my example code to see who of my new colleagues has ever read a book about programming in his life.

 

Contextual examples are sooo much more useful that X,Foo,Bar!

code of conduct - report abuse