Id vs ClassNameId for a class identifier's name

I'm in the middle of a debate here at work. Say you have a POCO named Person. Person has an identifier. I'm in the camp that says the identifier should be named Id.

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

The other camp says it should be named PersonId.

class Person
{
    public int PersonId { get; set; }
}

Is one more correct than the other?

I think that using Id is more readable and definitely less code to type.

The argument against Id is that it may be confusing because someone may not know if the ID belongs to a Person or an Addr开发者_如何学Cess. I think that argument falls flat if you just name your variables descriptively.

---

The real issue here is: what's your standard for naming variables that hold a reference?

 obj.Id         // Not good, better call it PersonId
 teamLead.Id    // Okay, quacks like a Person
 person.Id      // Okay, clear but not the greatest var name

I always pick good variables names without fail, I like Id :) The framework classes heavily favor plain Id.

---

Even if you don't name your variables descriptively, intellisense will give you the class if there's any doubt. I don't know from "more correct", but I personally use Id as long as the class will be clear during foreseeable use. If it is a situation where the class may be unclear during use (as, for example, in the case of tables in a database or attributes in an XML file), then I use ClassId. When it comes down to it, though, which you use is a really a matter of taste and either option isn't going to slow anyone down perceptably.

---

Id and PersonId are both good names for variables representing the unconcious part of the person's psyche that contains their basic drives. I'd slightly favour the former.

I'd prefer ID (not Id) for an identifier, since classes are namespaces (in the general, not .NET-specific, sense) and what it's an ID of is clear. I wouldn't get terribly upset about PersonID though (again, not PersonId).