Является ли плохой практикой называть свойство / элемент таким же, как объявленный тип в C #?

Например, такой класс:

class Dog { } //never mind that there's nothing in it...

а затем свойство как:

Dog Dog { get; set; }

Мне сказали, что если я не могу придумать более оригинальное название для этого, то я должен использовать:

Dog DogObject { get; set; }

Любые мысли о том, как назвать их лучше?

c# naming properties

— Буря Кирнан
источник

Это требование, о котором вам говорили, кажется мертвым, возможно, из-за чрезмерного применения хорошего руководства (не просто используйте имя типа, когда есть лучшее имя).

Это даже не скомпилируется в C #, поскольку имена членов не могут совпадать с типом включения.

— Ли

@ Ли: Я думаю, что контекст заключается в том, что это свойство другого типа. Например, Personкласс, содержащий Dogсвойство с именемDog

— goric

Я имею в виду, если она действительно собака, маркируйте ее таковой.

— Томас Эдинг

Подсветка синтаксиса в вашей среде IDE должна различать тип и свойство. Когда вы не используете IDE, вы всегда можете посмотреть на контекст.

— Cyanfish

Ответы:

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

Dog = new Dog();

Какой конструктор типа? Какой объект? Не смущен? Хорошо, как насчет

Dog = Dog.Create()?

Какой объект? Какой метод статической фабрики для типа? Все еще не смущен? Я так не думаю.

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

Dog = new Some.Namespace.Dog();

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

dog = new Dog();

— Роберт Харви
источник

+1. И альтернативы все хуже: «TheDog», «AnyDog», «MyDog» и т. Д. Когда нечего добавить, лучше ничего не добавлять.

— Кевин Клайн

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

— KDiTraglia

Мало того, что это разумная практика, язык был специально разработан для этого. Найдите в спецификации C # «Color Color» правила и обоснование и посмотрите

http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx

для некоторых интересных угловых случаев, которые возникают из этого решения.

Ни при каких обстоятельствах вы не должны называть свойство «DogObject», чтобы не называть его таким же, как его тип; это прямо противоречит руководству по проектированию рамок.

— Эрик Липперт
источник

Если тип свойства является типом, экземпляры которого не имеют идентичности (например Color), такое использование кажется разумным. Мне не очень нравится, хотя, с изменчивыми или IDisposableтипами. Относится ли «элемент управления Font» к тем аспектам состояния, которые инкапсулированы свойством, или к экземпляру, Fontидентифицированному получателем свойства?

— суперкат

Это прекрасно, Dogи это то, что Microsoft рекомендует в Руководстве по именованию :

РАССМОТРЕТЬ присвоение свойству того же имени, что и его тип.

Например, следующее свойство правильно получает и устанавливает значение перечисления с именем Color, поэтому свойство называется Color.

И вот пример, который они используют в приведенном выше руководстве:

public enum Color {...}
public class Control {
    public Color Color { get {...} set {...} }
}

— Исак Саво
источник