views:

476

answers:

9

This was something originally discussed during a presentation given by Charles Brian Quinn of the Big Nerd Ranch at acts_as_conference. He was discussing what he had learned from instructing a Ruby on Rails Bootcamp to many people both new to programming and new to Rails.

One particular slide that stood out was along the lines of never using foo and bar as examples when trying to teach someone to program. His reasoning was very simple.

Which is easier to understand?

baz = foo + bar

or

answer = first_number + second_number

It's happened many times myself when explaining something and I immediately jump to the go to foo bar placeholders but then realize my mistake and make the example make a lot more sense by using a real world scenario.

This is especially applicable when trying to teach someone who has had no programming exposure and you end up needing explain foo and bar before explaining what you're actually trying to teach.

However, using foo and bar for experienced programmers seems OK, though I personally think, along with Charles, that it's something that needs to change.

A quick SO search for "foo" returns over 20 pages of results with foo being used in more ways that I can comprehend. And in some cases where I'm reading a question on a particular language and I'm doing so to help understand that language better. If applicable variable names are used instead of foo and bar, it makes it much easier to understand and interpret the problem. So for seasoned developers, the construct seems a bit flawed as well.

Is this a habit that will ever be able to be kicked? Why do you choose to foo bar or to not foo bar?

+11  A: 

I can see the point when talking to non programmers, but when you're at a whiteboard discussing a problem with some team members .. I would miss my foos and my bars. I think the prevalence of foo/bar is an example of the ability of most programmers to think abstractly.

Probably more of an issue if you're in the training arena.

Niniki
Excellent point on thinking abstractly. That's something I never considered.
mwilliams
+4  A: 

I use them sometimes. But only if a "real" name is not relevant.

Gamecat
+26  A: 

It strictly depends on what are you trying to teach. Sometimes, when showing a programming example, you have to declare a few things just for the snippet to be "complete", and those few things are not the core of what you are showing.

For example, if you want to show how to throw an exception, I believe it is ok to present a snippet like

public void foo() { 

   // Do some things

   if (errorCondition) {
      throw new Exception("Error message");
   }

}

Since the point in it is showing exceptions, there is no point in caring about the method name, so foo is "legal" in this context, or at least for me.

What I would not accept (in this same example) would be

public void foo() { 

   // Do some things

   if (bar) {
      throw new Exception(baz);
   }

}

as it is obscuring what you are trying to teach.

Santiago Palladino
+1  A: 

I choose not to foo and bar whenever my audience is familiar enough with the concept at hand that it would prove a detriment to their understanding.

The only time Foo and Bar should be used is when you are talking about something so abstract that adding a context would require additional discussion. Then Foo and Bar are much more readable and created code that is more followable than the alternatives, like x, y and z.

tom.dietrich
+2  A: 

I use them when demonstrating that any values of 'foo' and 'bar' will suffice, like "you can get the size of an object with sizeof(foo)." It's handy for getting people to understand the general concept and not just the particulars. For instance, if I'd said "you can get the size of an object with something like sizeof(int)", then it's almost guaranteed that someone would ask if that also works for floats.

Just Some Guy
A: 

I am new to programming, and more or less self taught. I read a lot of example code online and at the beginning found myself replacing foo and bar &c. with more relevant names, such as the firstnumber and secondnumber examples above.

I now prefer x,y,z,i... because foo and bar seem to spark linguistic impulses in my mind and can distract me from the routine, and I've developed, somewhat, the ability to hold a whole bunch of different variables in my head and remember what they are. But I would still definitely recommend using relevant naming when teaching someone else, especially when explaining code to someone that doesn't program but needs to understand how the program works.

+1  A: 

I think it is due to mildly, or maybe not so mildly, sarcastic nature of many programmers. While many people have tried to place different meanings on foo/bar most , or at least many, of us think of "FUBAR", F**K Up Beyond All Recognition. Its a way for "experienced" people to make a snide comment about everyone else.

Because of this I never use it for non programmer and seldom use it even with experienced programmers. If I do use you can bet I am making a veiled reference to the subject at hand.

Jim C
A: 

On top of avoiding nonsensical words like foo & bar, I've found it's much more important to provide code examples for real-world scenarios which have the same relationships. This really helps a learner to understand a topic properly and prevents misunderstandings. E.g., if I'm teaching about Dependency Injection and show example code where an instance of the Car class is injected into the Driver class, no one's going to get confused and think "So that means the Car controls the Driver then?".

too much php
A: 

For totaly new programmer I have to say that terms foo and bar might not be known. I thought that they were something language specific (namely C), but after cheking Wikipedia I now know they are just abstract place holders. So if your audience consist of people who don't know meanings of them, something else is much clearer. Also first_number and so tells that those are numbers how ever they are presented and not something else.