Reputation: 2080
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 Address
. I think that argument falls flat if you just name your variables descriptively.
Upvotes: 0
Views: 297
Reputation: 941715
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.
Upvotes: 1
Reputation: 113302
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).
Upvotes: 0
Reputation: 12768
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.
Upvotes: 1