I somewhat agree with you, these names are not the best choice, however, they serve a very clear goal: to avoid any connection to the real domain. If someone gives an example with Clients and Orders, you would start thinking that orders should not have a link to the Client, and the OrderRepository would solve the problem in a more elegant way.
Abstracting away the meanings is the same trick which we've learned during the math class. We're not counting apples when we learn basic algebra, but we're working with a, b and c: a(b+c) = ab + ac sort of exercises.
When we see a we understand that it doesn't matter if it represents apples, dollars or vectors, what matter is the way functions are applied. When we see Foo and Bar we should focus on the language feature/pattern, but not the domain itself.
Thanks for reading. I agree about using abstract variables (like a(b+c)) to explain basic concepts. And I think something like this is just fine:
letfoo='Ohio State'letbar='USC'console.log(foo+' vs. '+bar);// ‘Ohio State vs. USC'
But even here, and maybe it’s splitting hairs, wouldn’t it makes sense to just name the variables let osu and let usc? What is the benefit to using foo and bar here over something that expresses what the variable actually means?
I would argue that your algebra example is very different than an association example. When creating a tutorial with associations, or where one piece of code relates to another in some way, it just doesn’t make sense to ever use abstracted names like foo, bar, or baz. I would also argue that if someone reads the tutorial and thinks a join table would be better, they probably already understand the concept of associations pretty well, ha. I think we can have the best of both worlds — focus on the language/pattern but also have the example have real world meaning.
That being said, I’m sure there are cases where it’s just fine to use abstracted names. Thanks for weighing in. I appreciate your input and I think it’s a good discussion to have.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I somewhat agree with you, these names are not the best choice, however, they serve a very clear goal: to avoid any connection to the real domain. If someone gives an example with Clients and Orders, you would start thinking that orders should not have a link to the Client, and the OrderRepository would solve the problem in a more elegant way.
Abstracting away the meanings is the same trick which we've learned during the math class. We're not counting apples when we learn basic algebra, but we're working with
a,bandc:a(b+c) = ab + acsort of exercises.When we see
awe understand that it doesn't matter if it represents apples, dollars or vectors, what matter is the way functions are applied. When we seeFooandBarwe should focus on the language feature/pattern, but not the domain itself.Thanks for reading. I agree about using abstract variables (like a(b+c)) to explain basic concepts. And I think something like this is just fine:
But even here, and maybe it’s splitting hairs, wouldn’t it makes sense to just name the variables
let osuandlet usc? What is the benefit to usingfooandbarhere over something that expresses what the variable actually means?I would argue that your algebra example is very different than an association example. When creating a tutorial with associations, or where one piece of code relates to another in some way, it just doesn’t make sense to ever use abstracted names like foo, bar, or baz. I would also argue that if someone reads the tutorial and thinks a join table would be better, they probably already understand the concept of associations pretty well, ha. I think we can have the best of both worlds — focus on the language/pattern but also have the example have real world meaning.
That being said, I’m sure there are cases where it’s just fine to use abstracted names. Thanks for weighing in. I appreciate your input and I think it’s a good discussion to have.