How would you name these related Property, Class, Parameter and Field in .NET?

Question

I often find I want to write code something like this in C#, but I am uncomfortable with the identifier names:

public class Car
{
    private Engine engine;
    public Engine Engine
    {
        get
        {
            return engine;
        }
        set
        {
            engine = value;
        }
    }
    public Car(Engine engine)
    {
        this.engine = engine;
    }
}

Here we have four different things called "engine":

• Engine the class. Engine seems like a good, natural name.
• Engine the public property. Seems silly to call it MyEngine or TheCarsEngine.
• engine the private field backing the property. Some naming schemes will recommend m_engine or _engine, but others say that all prefixes should be avoided.
• engine the parameter name on the constructor. I've seen naming schemes that recommend prefixing an underscore on all parameters, e.g., _engine. I really dislike this, since the parameter is visible to callers via Intellisense.

The particular things I don't like about the code as written are that:

• If you change the parameter name in the constructor but miss a use of it in the constructor body, you get a subtle bug that the compiler probably won't be able to spot.
• Intellisense has a bad habit of autocompleting the wrong thing for you, and sometimes you won't notice it's changed the case. You will again get a subtle bug if the constructor body accidentally ends up this.engine = Engine;

It seems that each name is appropriate in isolation, but together they are bad. Something has to yield, but what? I prefer to change the private field, since it's not visible to users, so I'll usually end up with m_engine, which solves some problems, but introduces a prefix and doesn't stop Intellisense from changing engine to Engine.

How would you rename these four items? Why?

(Note: I realise the property in this example could be an automatic property. I just didn't want to make the example overcomplicated.)

See also: http://stackoverflow.com/questions/461231/am-i-immoral-for-using-a-variable-name-that-differs-from-its-type-only-by-case

Answer 1

In this case, I would name them exactly as they are in the example.

This is because the naming is clear as to what data each element holds and/or will be used for.

The only thing I would change for C#3 is to use an auto-property which would remove the local variable.

Answer 2

• Member: m_engine;
• Static member: sm_engine;
• Parameter: engine
• Local variable: _engine
• Class: Engine
• Property: Engine

This makes it possible to name parameters and local variables differently.

Answer 3

I prefer to use some prefix (I use '_') for private fields, otherwise they look just the same as parameters and locals. Other than that, I use a similar approach to naming as you do here, though Engine might be a little to generic, depending on how general the program is.

I think I prefer CarEngine, or AutoEngine, or something like that, since programmers are fond of using Engine as a metaphor for things that don't correspond to real-life engines at all.

Answer 4

I normally prefix private fields with underscore, so I would call it _engine. And I often use very short (e.g. initial letter) parameter names, so that would be Engine e (after all, the intellisense users get the type and name). I either leave the class and object names the same or (more usually) come up with a different name, even if it's MyEngine or carEngine.

So:
public class Car

{    
    #region fields

    private Engine _engine;

    #endregion

    #region public properties

    public Engine carEngine { get { return _engine; } set { _engine = value; } }  

    #endregion 

    #region constructors 

    public Car(Engine e)    
    { 
        _engine = e; 
    }

    #endregion
}

Answer 5

For private members I always prefix with an underscore:

private Engine engine;

becomes:

private Engine _engine;

Whenever I see m_, it makes my stomach churn.

Answer 6

I don't like the Hungarian notation: m_foo, etc. I'm using the camel style: engine, myEngine, myBigEngine.

I would write exatly as you.

In MSDN I saw one remark: use public Car(Engine e) - I mean name input parameter something else as local variable. But I don't do that.

Answer 7

Like this:

public class Car
{    
    #region fields

    private Engine _engine;

    #endregion

    #region public properties

    public Engine Engine { get { return _engine; } set { _engine = value; } }  

    #endregion 

    #region constructors 

    public Car(Engine engine)    
    { 
        _engine = engine; 
    }

    #endregion
}

Sadly the SO code stylesheet is eliding my blank lines, which make it a bit clearer and easier to read. The region directives, which we use on all production code, help avoid confusion. The underscore prefix is the only prefix I use (well, except for I on interfaces but everyone does that) but I do use it religiously, so we never confuse fields and locals (as in the contstructor). I see no major problem with having the property name and type name the same (in VS the highlighting will differentiate between them). It's only a problem if you try to use a static member or method of the type, and if you do then you'll either have to alias it or refer to it explicitly (ie MyNamespace.VehicleParts.Engine.StaticMethod()).

Seems readable to me, but it's all very subjective.

Answer 8

It's ok to leave them as they are apart from one small thing. In intellisense, it's not immediately obvious whether an item is a parameter, local or private member as they all have the same symbol (blue cube). If, however, you move cursor to a particular item then the tooltip tells you which of these it is.

As a visual aid, you may want to prefix your private member with an underscore, _engine so that it's immediately obvious that it is a private member without having to move the cursor. This is a convention which I use and it is the only name I would change in your example.

Answer 9

public class Car
{

    public Car(Engine engine)
    {
        Engine = engine;
    }

    public Engine Engine { get; set; }

}

If I had a field, I prefix it with an underscore (_). So private Engine engine; would turn into private Engine _engine;