Especially when working with some kind of ORM like Entity Framework I often see classes like:

public class Foo { public int FooId { get; set; } }

accessing the id will look like foo.FooId

Is there any logical reason why is this preferred over just naming it Id?

public class Foo { public int Id { get; set; } }

Accessing it seems more OOP and logical than previous example: foo.Id

This might be stupid or opinion-based but to me, it just doesn't look right. If you use it could you explain why you do it this way? I know it's just a naming/naming convention but I don't understand why someone would name things this way.

  • 2
    I think that people who use this kind of naming convention come from non OOP Language and didn't loose their habits. – Freddykong Aug 22 '18 at 10:27
  • 3
    The short answer is that they don't realise that this is unnecessary. The longer answer is that people don't naturally have a good appreciation of scope, any more than even computer users naturally understand hierarchical file systems. Look at the desktop of any casual computer user and despair! It seems to me that this is one of those concepts that seems natural to the very particular breed of mind that is attracted to computer programming, but is actually rather hard to grasp. – Kilian Foth Aug 22 '18 at 10:42
  • 4
    Welcome to smurf naming convention. – Flater Aug 22 '18 at 10:43
  • 2
    @robertharvey The question is asking about property names in OO languages, not field names in databases. While I personally don't find the argument compelling in any case, that's irrelevant as every ORM I've ever used allows you to have different names for the two, so your database naming scheme shouldn't constrain your oop scheme. – Jules Aug 22 '18 at 16:35
  • 2
    The pushback is because property names that include the containing class name becomes redundant noise. What's better: "var name = procedure.ProcedurePatient.PatientName;" or "var name = procedure.Patient.Name;" – 17 of 26 Aug 22 '18 at 17:53

In database design it is often so that in a foreign key relationship both fields on either side of the relationship get the same name.

For example:

  • bookings.booking_id (primary key)
  • payments.payment_id (primary key)
  • payments.booking_id (foreign key to bookings.booking_id)

The use of a primary key column name that is unique across the schema makes it easy to have the foreign key column have the same name as the primary key it points to.

In such cases, when using an ORM, it is natural and convenient to use the same name in the ORM entities, but with different casing. Once a developer gets into this habit, they will apply it everywhere, even in non-ORM code. That doesn't make it right, but it explains why it happens.

  • 2
    Yeah, but I think you also have the ability to change column name to map to properly named property. I think it's bad when database dictates the naming of your properties. Especially when doing code-first, it should be otherwise. – Konrad Aug 22 '18 at 11:28
  • 2
    @Konrad: So you propose to use aliases everywhere because you need to map one name to another for the sake of some coding convention? No thanks. – Robert Harvey Aug 22 '18 at 15:08

Having the long name FooId makes it possible to find all uses of the property anywhere in your source code, which is useful to have. On the other hand, you may have an editor that can search for symbols and keeps the Id properties of different classes apart. Or you have a refactoring tool that can show you all uses of a symbol.

If you don’t have such tools or you don’t know about them, long names are useful.

  • 4
    I don't think it's a good argument because any good IDE can do that. There's a feature like "Find all references" or "Find all usages" and naming doesn't matter. Also when naming it just Id you can have a base class and inherit from that class so you don't have to put Id property everywhere. – Konrad Aug 22 '18 at 11:25
  • "If you don't have such tools or you don't know about them" – gnasher729 Aug 22 '18 at 18:09

Prefixing class properties with its name isn't normal and a very weird practice. But if you are talking in Entity Framework context, you might sometimes see something like this, where you see a navigation property id with the name prefix:

public class Foo {
    public int Id { get; set; }

    public Bar Bar { get; set; }

    public int BarId { get; set; }

Entity Framework implicitly knows to map BarId to Bar.Id, thus allowing you to assign navigation properties while lazy loading.


It's definitively not a good practice under "normal" circumstances, as all it really does is add clutter, and so it has a negative impact on readability (generally speaking).

However, there could be other considerations, other driving forces that could lead to code with this kind of naming. For example, some tools rely on naming conventions (and some sort of reflection/introspection capability) to generate boilerplate code between two collaborating systems. It's in the spirit of the "convention over configuration" approach. The easiest thing to do there is to make the corresponding fields/properties have the same name, and it's often useful to have them unambiguously identify their parent type (or table, or whatever higher-level structure there is), so that you don't have to check all the time. And, while naming conventions vary between systems, languages and technologies, you have to come up with a unified approach here, so the end-result may not follow the best OOP practices.

This was just one example, but as you can imagine, as people come up with new tools and technologies, all kinds of real-word factors arise that may lead to these departures from "the norm".

Of course, there's always the other side of the coin, and sometimes people write code that looks like this without really having good justification for it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.