I’ve had it with Foo and Bar. They are right out. For too long we programmers have put up with these sorry excuses for example classes in documentation, lectures, examples, and now that TDD is all the rage, tests.
There is no standard for the relationship of Foo and Bar.
Standards in examples and relationships are full of time-saving goodness. Take for example the Northwind database. Recently there’s been a big push for replacing Northwind with some other database standard. One of the chief arguments against the “Not Northwind” mafia are the magic words, “I’m using Northwind for my database”. *Poof* everyone in the audience knows the relationships inherent in the system.
But Foo and Bar have no default relationship. In the NHibernate project there are 8 different Foo classes, 2 Bars, and 1 FooBar. One of those is actually even in the NHibernate.DomainModel namespace, most of the remainder are in the SpecificTest folder. Different developers have created tests relying on Foo and Bar, and when debugging these tests I have no idea what the properties, entities, or relationships should be.
A sampling of different properties shows that some Foos have Descriptions, while others have Names, Words, Numbers. Some have other Foo as children, while others have Bar as children. Sometimes a FooBar will have a Foo or Bar property….
Please, if you submit a patch to an Open Source project… or any project for that matter, don’t use Foo or Bar. Use People and Pets, Cities and Houses, Sales Orders and Sales Line Items, Customers and Orders… any number of obvious relationships that readers won’t need to review the class in order to understand. Foo and Bar slow the reader down… even if you’re the one that wrote it.