Вы группируете частные поля или кладете их вместе с их собственностью?
Я видел (и использовал) в различных проектах этот макет с группой полей, за которыми следует группа свойств:
private int MyIntField;
private string MyStringField;
public int MyInt {
get { return MyIntField; }
set { MyIntField = value; }
}
public string MyString {
get { return MyStringField; }
set { MyStringField = value; }
}
Еще я встречал этот макет с полями рядом с их свойством:
private int MyIntField;
public int MyInt {
get { return MyIntField; }
set { MyIntField = value; }
}
private string MyStringField;
public string MyString {
get { return MyStringField; }
set { MyStringField = value; }
}
Есть ли причина считать одно лучше другого? Я думаю, что большинство стандартов кодирования рекомендуют вариант №1, но иногда удобно иметь поле рядом со свойством, которое с ним работает.
Примечание: я предполагаю нетривиальные свойства, которые не могут использовать автоматически реализуемые свойства.
Ответы 6
Я думаю, это то, чем комфортно себя чувствует команда. Определитесь со стандартом для проекта / компании / языка и придерживайтесь его. Я предпочитаю частные переменные все вместе, методы / интерфейсы вместе, частные члены .... Я думаю, вы поняли.
Я группирую их среди лучших в классе.
Фактически, единственное, что находится над моим частным атрибутом, - это все константы класса.
Я бы использовал второй подход, поскольку это соглашение, которое помогает мне с первого взгляда увидеть, имеет ли частный член общедоступный метод получения / установки или нет. Хотя в любом случае не так уж и много.
Чтобы повторить то, что сказал Кенни выше, на самом деле все дело в стандартах кодирования вашей организации. Трудно объективно отличить один стиль от другого, хотя, похоже, у каждого свое мнение.
Обычно я предпочитаю иметь группы данных и методов по модификатору доступа, поэтому в этом случае предпочитаю вариант №1. Это сделано для того, чтобы подчеркнуть интерфейс, а не дизайн. То есть я мог бы прозрачно изменить реализацию модификатора MyInt в будущем (возможно, мне действительно не нужно хранить поддерживающую переменную).
Мне нравится, когда поля сгруппированы вверху, а свойства - где-то еще. Это также то, что рекомендует Microsoft StyleCop.
В качестве побочного примечания, где подходят авто свойства?
Также см. порядок-элементов-в-классах-поля-свойства-конструкторы-мет hods