Правильное использование этого. в конструкторе класса

Question

Я просматривал документацию для библиотеки физики для XNA и заметил пример, который кто-то использовал для создания класса для автомобиля.

Это довольно простой пример:

Class Car 
{ 
    private float gravity; 
    private float maxSpeed; 

    public Car(float gravity, float maxSpeed) 
    { 
     this.gravity = gravity; 
     this.maxSpeed = maxSpeed; 
    } 
} 

Теперь, когда я создал конструктор и настроить присвоение переданная в параметрах я хотел бы сделать это таким образом:

Class Car 
{ 
    private float _gravity; 
    private float _maxSpeed; 

    public Car(float gravity, float maxSpeed) 
    { 
     _gravity = gravity; 
     _maxSpeed = maxSpeed; 
    } 
} 

Есть ли какое-либо преимущество для любого подхода? Я встречался с этим несколько раз, но я полагаю, что для этого есть веская причина, я просто ищу способ «лучшей практики», так сказать.

Спасибо!

Answer 1

Оба примера функционально идентичны, и оба метода используются разными людьми. Это зависит от вас, с которым вы соглашаетесь. Если вы дадите поле то же имя, что и параметр, то вам нужно будет использовать для доступа к нему.

Важная вещь - быть последовательной в своем наименовании. Я лично предпочитаю обращаться к полям с ключевым словом this, но здесь определенно много людей, похожих на подчёркнутый подход.

Подчеркивание:

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

Нет Подчеркивание:

Если вы не префикс для ваших частных полей с подчеркивания, то у вас есть вариант ссылаться на него непосредственно или через this ключевое слово. Это означает, что можно забыть, и в вашем примере вы можете назначить аргумент самому себе: gravity = gravity; Это должно хотя бы генерировать предупреждение. Если вы используете инструмент StyleCop, то он по умолчанию будет обеспечивать, чтобы вы всегда получали доступ к закрытым полям через ключевое слово this.

Смотрите эти же вопросы для более ответов:

• To underscore or to not to underscore, that is the question
• Underscore prefix on member variables. intellisense
• C# member variables/fields naming convention
• C# Field Naming Guidelines?

Answer 2

Оба являются общими подходами, и оба они прекрасно подходят.

Лично я предпочитаю первое, потому что я считаю, что подчеркивания являются уродливыми. Но многие предпочитают иметь подчеркивания, потому что они помогают идентифицировать, что переменная является членом класса, а не локальной переменной.

Answer 3

С появлением автоматических свойств, это становится довольно популярным, как хорошо ...

public class Car 
{ 
    public Car(float gravity, float speed) 
    { 
    Gravity = gravity; 
    Speed = speed; 
    } 

    protected float Gravity { get; private set; } 
    ... 

Я лично предпочитаю этот подход, хотя я ненавижу то, что вы не можете отмечать автоматическое свойство как только для чтения.

Answer 4

Либо хорошо. Лично я предпочитаю подход this., особенно с появлением autoproperties. например: public string Something {get; set;}. Оставляя имя аргумента конструктора так же, как имя свойства, дает пользователю вызов кода очень четкое указание на то, где значение будет в конечном итоге.

Answer 5

Если вы когда-нибудь попадались Resharper, вот некоторые из его конвенций по умолчанию:

• Глобальные переменные объявляются с подчеркиванием.

  строка _variable1;

• Глобальная переменная, которая является константой, должна быть объявлена ​​в верхней CamelCase.

  const string Variable1;

• Свойства всегда должны находиться в верхней части CamelCase.

  строка Variable1 {получить; набор;}

Я не могу быть поклонником подчеркивания, но я вижу, как они помогают вам определить области.

Answer 6

Есть некоторые проблемы с читабельностью, которые «это» может помочь решить проблему. Я был во многих ситуациях, когда я читаю код someones, чтобы понять, как он работает, или как я могу извлечь из него. Чтение через кучу сложных взаимосвязанных классов, и вы найдете что-то вроде

var foo =_FatNumber; 

Таким образом, вы начать поиск _FatNumber и не может найти его определить. Это потому, что он находится в базовом классе. если он помечен base.Fatnumber, который вы знаете, чтобы не беспокоиться о том, чтобы смотреть здесь, в то время как this.SlimNumber очень явный. Я бы рекомендовал явно обозначать, кто объявляет переменные (обычно это контроллер var). Возможно, это только проблема с более сложными производными классами, но это спасло бы меня много времени, чтобы понять поведение класса.

, например:

public class FooBase 
{ 
    protected int Foo { get; set; } 
} 

public class FooDerived : FooBase 
{ 
    int Bar = 9; 

    public int GetTheThing(bool something) 
    { 
     if (somthing) 
      return this.Bar; 
     else 
      return base.Foo; 
    } 
}