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...
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.