Naming Conventions for Property Types

Question

If you a have Person Property on Address defined like

public class Address
{
   public int AdressId {get; set;}
   public Person AddressesPerson {get;set;}
   public string FullAddress {get; set;}
}

What is the proper conventions, if any, for naming a property of another type?

Answer 1

Name the property according to its semantic meaning. Frankly it's quite odd to have a Person property on an address - it would normally be the other way round. What's the meaning of the person here? What's the association between the address and the person? You might have Owner or Resident, for example - but in other cases that wouldn't be appropriate.

Answer 2

I would name the property from the relationship between the two types, e.g. Resident, Owner etc.

Answer 3

I don't think there's a hard and fast rule, but generally I like to stick to the following guidelines as much as possible:

• Don't repeat the name of the class. This one can be surprisingly hard to work around, but it's usually solved by thinking hard about the second rule:
• Think about the properties role in the class, and not just what it is. In your example, Owner might be an appropriate property name, since a Person owns a particular Address.

Answer 4

Pick one and stick with it.

In your specific case, I wonder why a person is subordinate to an Address, instead of the other way around, but basically just pick the one you want to use and keep using it. As long as it's not something completely unreadable or against some kind of Team coding guidelines, you're probably good.