Confusing property names

[Mark]

I'm struggling with how to properly name a specific subset of Properties in
my classes. An example will illustrate it best. Let's say you have a class
named Person with the code below. Each Person instance has a single Address
instance. The Property name is Address, but it returns an instance of type
Address. This results in the code "public Address Address" below when
defining the property. It doesn't make sense to make the property name be
GetAddress since it has a GET and SET. Making the first character of the
property lower case would be confusing too since you could have a field or
variable called "address" which matched it.

Goofy - yes. Any recommendations?

Note - this is just bogus data to make my point, I'm not actually working
with Person and Address classes.


public class Person
{
private string _firstName;
private Address _address;

public Person (firstName)
{
_firstName = firstName;
_address = new Address("123 Washington Dr.");
}

public Address Address
{
get { return _address;}
set { _address = value;}
}

public bool FooBar()
{
//Do something with the address.
Address address = Address;

//Yikes - this creates a local instance of address using the
property Address.
//I agree that this might not be good style regardless of the naming
convention, but it illustrates my problem well.
}

public string FirstName
{
get { return _firstName;}
set { _firstName = value; }
}
}

 

[Paul E Collins]

The Property name is Address, but it returns an instance
of type Address. This results in the code "public Address
Address" below when defining the property.

I think that's acceptable. In fact, the standard .NET classes have
this kind of thing: consider Pen.Color and Control.Size.

Your line ...
Address address = Address;
.... seems a bit pointless, given that a class does not need to hide
information from itself (and therefore does not need to use its own
properties), but anyway I'd prefer ...
Address address = this.Address;

P.

 

[Chris R. Timmons]

Mark,

I disagree with Paul. Writing maintainable code is hard enough
without using the same identifier for a type name and variable name.

In the rare cases where this arises in my code, I rename the type to
something like "AddressClass" or "AddressStruct".

 

[Daniel O'Connell [C# MVP]]

Mark,

I disagree with Paul. Writing maintainable code is hard enough
without using the same identifier for a type name and variable name.

And I disagree with you, . Types and properties which happen to share a
name are going to happen in any halfway clear design and postfixing a class
type to the actual type name has potential issues(such as the type name
having to change if the type usage changes and "what the hell was the
designer thinking" questions). You simply cannot realistically try to keep
your type names from conflicting with property names in all cases, you might
be able to avoid a property that has the same identifier for its name and
type by mangling your type names, but you will not achieve it globally
without throughly confusing your code.

I'd rather deal with common identifiers over resorting to prefixes or
postfixes to avoid potential conflicts.

 

[Picho]

I have to say that Microsoft once said (maybe in C# language reference?)
that this is the way to do it...

public Adress Adress
{
get{...}
set{...}
}

this is regardless of the question if this is good or bad...