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.
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
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:
bar0 = process0()
barN = processN()
baz = doing_stuff(bar0, ..., barN)
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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.