Как Вы назвали бы, они связали Свойство, Класс, Параметр и Поле в.NET?

Для членов парламента, не занимающих официального поста я всегда префикс с подчеркиванием:

private Engine engine;

становится:

private Engine _engine;

Каждый раз, когда я вижу m_, это заставляет мой живот крутиться.

Как это:

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
}

Печально, ТАКИМ ОБРАЗОМ, таблица стилей кода игнорирует мои пустые строки, которые делают ее немного более ясной и легче читать. Директивы региона, которые мы используем на всем производственном коде, справка, избегают беспорядка. Префикс подчеркивания является единственным префиксом, который я использую (хорошо, за исключением меня в интерфейсах, но все делают это), но я использую его неукоснительно, таким образом, мы никогда не путаем поля и местных жителей (как в contstructor). Я не вижу основной проблемы с наличием имени свойства и имени типа то же (в VS, который выделение будет дифференцировать между ними). Это - только проблема, при попытке использовать статического участника или метод типа, и если Вы делаете затем, необходимо будет или исказить его или обратиться к нему явно (т.е. MyNamespace.VehicleParts.Engine.StaticMethod()).

Кажется читаемым мне, но это все очень субъективно.

• Участник: m_engine;
• Статический участник: sm_engine;
• Параметр: механизм
• Локальная переменная: _engine
• Класс: механизм
• Свойство: механизм

Это позволяет назвать параметры и локальные переменные по-другому.

Я предпочитаю использовать некоторый префикс (я использую '_') для частных полей, иначе они смотрят все равно как параметры и местные жители. Кроме этого, я использую аналогичный подход к именованию, как Вы делаете здесь, хотя Механизм мог бы быть немного к дженерику, в зависимости от того, насколько общий программа.

Я думаю, что предпочитаю CarEngine, или AutoEngine или что-то как этот, так как программисты любят использование Механизма как метафора для вещей, которые не соответствуют реальным механизмам вообще.

Мне не нравится Венгерская запись: m_foo, и т.д. Я использую стиль верблюда: engine, myEngine, myBigEngine.

Я записал бы exatly как Вы.

В MSDN я видел один комментарий: использовать public Car(Engine e) - Я имею в виду входной параметр имени что-то еще как локальная переменная. Но я не делаю этого.

Нормально оставлять их, как они кроме одной мелочи. В intellisense не сразу очевидно, является ли объект параметром, локальный или член парламента, не занимающий официального поста, поскольку у них всех есть тот же символ (синий куб). Однако, при перемещении курсора в конкретный объект затем, подсказка говорит Вам, которые из них это.

Как визуальная помощь, можно хотеть снабдить префиксом члена парламента, не занимающего официального поста подчеркивание, _engine так, чтобы было сразу очевидно, что это - член парламента, не занимающий официального поста, не имея необходимость перемещать курсор. Это - конвенция, которую я использую, и это - единственное имя, которое я изменил бы в Вашем примере.

public class Car
{

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

    public Engine Engine { get; set; }

}

Если у меня было поле, я снабжаю префиксом его подчеркивание (_). Так частный механизм Механизма; превратился бы в частный Механизм _engine;

Я обычно снабжаю префиксом частные поля подчеркивание, таким образом, я назвал бы его _engine. И я часто использую очень короткий (например, первая буква) названия параметра, так, чтобы был бы Механизм e (в конце концов, intellisense пользователи получают тип и имя). Я или оставляю имена классов и имена объектов тем же или (чаще) придумываю другое имя, даже если это - MyEngine или carEngine.

Так:
общедоступный класс Автомобиль

{    
    #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
}