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?
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.
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.
I use them sometimes. But only if a "real" name is not relevant.
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.
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.
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.
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.
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?".
I think there is another important reason for using foo and bar in examples. These names make it clear that you are not invoking any magic keywords. Whenever I am reading some documentation or code examples, I like the arbitrary parts of the example to be clearly distinguished from the necessary parts.
If you substituted the nonsense word for what it generically represents in the example code, you might end up with some names that look a lot like the keywords, classes, or methods you're trying to explain. The "my" prefix, as in myNumber, myFunction, is a good compromise that makes names stand out as being arbitrary.
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.
来源：https://stackoverflow.com/questions/234507/to-foo-bar-or-not-to-foo-bar-that-is-the-question