Are variables named the same as the class bad practice?

Question

Possible Duplicate:
Giving a property the same name as its class

I will frequently do/see this for local variables:

MyObject myObject = new MyObject();

I occasionally get stuck with my naming convention that has public properties capitalized. Something like this:

public MyObject MyObject { get; set;}

Is this bad? The compiler knows, but I code more for those who must maintain what I code then for the compiler.

Is there an accepted best practice on this?

Answer 1

I think a good idea is to not name your class 'object'.

MyClass MyObject = new MyClass();

Then you won't have a problem. In general giving things the same name is bad news. It really makes searching through code a pain.

Answer 2

I would simply give it a better name. You won't name your variable like this, would you?

public String String { get; set;}  

Other things to watch for. It is not just for variables. It could be your namespace.

e.g.

namespace FootballDao
{
     class FootballDao
     {
     }
}

Answer 3

If the class that will be used as a property is descriptively named and would be the best property name as well, I do it when it seems clear to me, e.g.:

public class ContactInfo
{
   //...
}

public class Person
{
    //...
    public ContactInfo ContactInfo { get; set; }
    //...
}

public class Company
{
    //...
    public ContactInfo ContactInfo { get; set; }
    //...
}

Answer 4

I note that this is a duplicate of

http://stackoverflow.com/questions/1095644/giving-a-property-the-same-name-as-its-class

and

http://stackoverflow.com/questions/1746117/why-is-it-possible-to-have-properties-named-the-same-as-their-return-types

It is a perfectly acceptable practice; the C# language has been carefully designed so that this is legal and practical. Of course, if you can easily avoid it, do so. But if you cannot, don't stress about it.

The canonical example is a type called Color, and a property called Color. It doesn't make any sense to rename either of them, so you end up with

public Color Color { get { ...

This is known as the "Color Color" problem. For some additional thoughts on the implications on the design of C#, see my article on the subject:

http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx

Answer 5

Yes, it is a bad idea in most cases.

A good naming convention is to assign descriptive identifiers to various programming elements (classes, variables, methods and so on) to make them as self-documenting as possible.

Variables typically exist in relatively narrow scopes and their names should clearly state the role they play in the specific context they are used in. Types, on the contrary, operate at a wider level and should be named accordingly.

For example you do write:

Order lastProcessedOrder;
bool isOrderValidated;

and you don't write:

int integer;
bool boolean;

If these naming rules are followed, it should come naturally that variables in most cases don't share the same name as the type they represent.