I agree with your post--thanks! Using foo, bar, and baz can teach non-self-documenting code. As you mentioned with your example the variable should have meaning since the data itself (Ohio State/USC) is a concrete example, e.g.:
letteam1='Ohio State'letteam2='USC'console.log(team1+' vs. '+team2);// ‘Ohio State vs. USC'
(By the way, that example would provide a great way to lead into arrays, where the foo/bar snippet wouldn't as readily)
letteam[0]='Ohio State'//etc
I saw this example about overriding in PHP on StackOverflow:
Sure I can figure out what's going on in a few seconds. But all the while I have to not only understand what I'm learning, but ALSO at the same time mentally hold on to the meaning of what foo/bar mean. That is extra mental work, and--especially when you've already been working or learning for many hours--it's extra mental work that just isn't necessary. When I just read the echo comments, it's not apparent what happened. If we write self-documenting code, we can see more quickly and clearly what happened in the code. For example:
Note this is not concreteness--you would probably rarely if ever use these names in real-world code, but concepts are built into the code to teach as you read rather than having to deal with the extra layer of meaningless foo/bar/baz.
While this is more readable for you, consider someone coming into it as a new programmer. Would they now think that all their parent classes have to be named Base, and child classes called Extended, rather than if it was Foo and nonsensical? Foo should be part of every student's vernacular. Just like x and y for math majors.
Foo and Bar stuff is INCREDIBLY hard to read/understand.
No matter if you know they are just placeholders or not.
Even var1 and var2 or func1 and func2 would be miles easier to understand than this crap.
My brain tries to assign some sort of logic to a variable while trying to understand the code.
With foo and bar its nearly impossible...
If someone is to the point where they're looking into extending classes, it has likely been well established in their mind that a class name is the coder's choice and they likely know that there are general rules (e.g. certain keywords can't be used and that those keywords are case sensitive and can't start with a number, etc., etc.) But to your point, many examples use "My" or something as a prefix for that very reason, and that would make sense to do so in the example above for clarity. I don't think a minor flaw in my example negates the main points of what I was saying. It is your opinion that foo/bar/baz should be part of every student's vernacular, and that may well be true for the sole reason that it became an ill-used tradition at some point thereby warranting that need. If you look an a more extreme example where I was needing to hold on to 15 conceptual pieces you could extend out your foo/bar/baz vernacular to an impressive foo/bar/baz/buz/fuz/foz/faz/friz/biz/boz/bir/bur/fyz/bor/fuu and really write some interesting example code. Before I did the replacements in this example below I could read through it in a few seconds and use the concrete names (users, patients, company, etc) and see exactly what the conceptual goal of the code was. While I understand exactly what is happening on every line of the foo/bar/baz replaced code below, it's not a quick thing to see what the entire section of code is trying to accomplish.
<?php
public class Baz{
}
public class Buz{
public function getFuz(){
$fuz0 = new stdClass();
$fuz0->bir = 'bir0';
$fuz1 = new stdClass();
$fuz1->bir = 'bir1';
return [$fuz0, $fuz1];
}
}
public class Faz{
public static function getFaz(){
$faz = new stdClass();
$faz->boz = 1;
}
}
private function getBar(){
return new stdClass();
}
public function foo()
{
$bar = $this->getBar();
$baz = new Baz();
$buz = new Buz();
$buzId = NULL;
if ($bar->fuz == 'bar' || $bar->fuz == 'boz') {
$buzId = $bar->id;
}
// get list all fuzzes
$fuz = $buz->getFuz($bar->foz);
$faz = Faz::getFaz($bar->foz);
$friz = [];
foreach ($fuz as $biz) {
if ($faz->boz == 1 || !$biz->bir) {
$biz->bir = $biz->id;
}
$friz['bur'][$biz->bir]['bur_id'] = $biz->bir;
$friz['bur'][$biz->bir]['fyz'] = $biz->fyz;
$friz['bur'][$biz->bir]['bor'] = $biz->bor;
$friz['bur'][$biz->bir]['fuu'] = $biz->fuu;
}
// ...
}
Examples that illustrate a new concept to someone should, in my opinion, not carry the extra conceptual overhead of meaningless names, since understanding the new concept is mental work enough. Commonly people learn by example. Concrete names can be themselves inherent example fragments that contribute to the example as a whole. Without them the overall example is weakened.
people are ignorant and they will never change...
examples like the many ones you provides should be more than enough reason to stop using foo/bar
foo/bar users should maybe skip high-level programming all together and write their code in Assembler just addressing registers and shuffling values around -
because it is apparent that they have no interest in producing readable code anyway...
I agree with your post--thanks! Using foo, bar, and baz can teach non-self-documenting code. As you mentioned with your example the variable should have meaning since the data itself (Ohio State/USC) is a concrete example, e.g.:
(By the way, that example would provide a great way to lead into arrays, where the foo/bar snippet wouldn't as readily)
I saw this example about overriding in PHP on StackOverflow:
Sure I can figure out what's going on in a few seconds. But all the while I have to not only understand what I'm learning, but ALSO at the same time mentally hold on to the meaning of what foo/bar mean. That is extra mental work, and--especially when you've already been working or learning for many hours--it's extra mental work that just isn't necessary. When I just read the echo comments, it's not apparent what happened. If we write self-documenting code, we can see more quickly and clearly what happened in the code. For example:
Note this is not concreteness--you would probably rarely if ever use these names in real-world code, but concepts are built into the code to teach as you read rather than having to deal with the extra layer of meaningless foo/bar/baz.
While this is more readable for you, consider someone coming into it as a new programmer. Would they now think that all their parent classes have to be named Base, and child classes called Extended, rather than if it was Foo and nonsensical? Foo should be part of every student's vernacular. Just like x and y for math majors.
Foo and Bar stuff is INCREDIBLY hard to read/understand.
No matter if you know they are just placeholders or not.
Even var1 and var2 or func1 and func2 would be miles easier to understand than this crap.
My brain tries to assign some sort of logic to a variable while trying to understand the code.
With foo and bar its nearly impossible...
No.
If someone is to the point where they're looking into extending classes, it has likely been well established in their mind that a class name is the coder's choice and they likely know that there are general rules (e.g. certain keywords can't be used and that those keywords are case sensitive and can't start with a number, etc., etc.) But to your point, many examples use "My" or something as a prefix for that very reason, and that would make sense to do so in the example above for clarity. I don't think a minor flaw in my example negates the main points of what I was saying. It is your opinion that foo/bar/baz should be part of every student's vernacular, and that may well be true for the sole reason that it became an ill-used tradition at some point thereby warranting that need. If you look an a more extreme example where I was needing to hold on to 15 conceptual pieces you could extend out your foo/bar/baz vernacular to an impressive foo/bar/baz/buz/fuz/foz/faz/friz/biz/boz/bir/bur/fyz/bor/fuu and really write some interesting example code. Before I did the replacements in this example below I could read through it in a few seconds and use the concrete names (users, patients, company, etc) and see exactly what the conceptual goal of the code was. While I understand exactly what is happening on every line of the foo/bar/baz replaced code below, it's not a quick thing to see what the entire section of code is trying to accomplish.
Examples that illustrate a new concept to someone should, in my opinion, not carry the extra conceptual overhead of meaningless names, since understanding the new concept is mental work enough. Commonly people learn by example. Concrete names can be themselves inherent example fragments that contribute to the example as a whole. Without them the overall example is weakened.
people are ignorant and they will never change...
examples like the many ones you provides should be more than enough reason to stop using foo/bar
foo/bar users should maybe skip high-level programming all together and write their code in Assembler just addressing registers and shuffling values around -
because it is apparent that they have no interest in producing readable code anyway...
Been years since I wrote this, but I don’t think there is ever an appropriate time to use foo/bar variables.