CODEWITHSUNDEEP
c#.net
Weeble
Weeble

Reputation: 17940

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

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":

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

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: Am I immoral for using a variable name that differs from its type only by case?

Upvotes: 13

Views: 450

Answers (9)

Serhat Ozgel
Serhat Ozgel

Reputation: 23766

  • 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.

Upvotes: 1

gkrogers
gkrogers

Reputation: 8356

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
}

Upvotes: 0

Chris Brandsma
Chris Brandsma

Reputation: 11736

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;

Upvotes: 0

Adam Ralph
Adam Ralph

Reputation: 29956

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.

Upvotes: 0

Neil Hewitt
Neil Hewitt

Reputation: 2518

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.

Upvotes: 3

abatishchev
abatishchev

Reputation: 100308

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.

Upvotes: 0

Kev
Kev

Reputation: 119836

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.

Upvotes: 5

Barry Kelly
Barry Kelly

Reputation: 42152

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.

Upvotes: 0

Garry Shutler
Garry Shutler

Reputation: 32698

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.

Upvotes: 12

Related Questions