Как вы решаете общее столкновение имен между типом и объектом?

Поскольку стандартное соглашение С# состоит в том, чтобы загладить первую букву общедоступных свойств, старое соглашение об исходном капитале типа С++ для имен типов и начальное строчное значение для имен не-типа не предотвращает столкновения классического имени, где наиболее очевидное имя объекта соответствует имени типа:

class FooManager
{
    public BarManager BarManager { get; set; } // Feels very wrong.
                                               // Recommended naming convention?
    public int DoIt()
    {
         // 1st and 2nd Bar Manager are different symbols 
         return BarManager.Blarb + BarManager.StaticBlarb;                                                                          
    }
}

class BarManager
{
    public        int Blarb { get; set; }
    public static int StaticBlarb { get; set; }
}

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

ОТВЕТЫ

Ответ 1

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

Эрик Липперт сообщение в блоге по этой точной теме.

Однако для компилятора нет никакой двусмысленности.

Ответ 2

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

Ответ 3

Я в порядке с этим честно - если ваши статические методы/члены не являются, очевидно, статичными по имени и по назначению, у вас больше проблем, чем столкновение имен.

Ответ 4

Я не думаю, что это когда-либо вызывало проблему для меня. Ниже приведены общие условные обозначения для свойств. Единственное, что helpful может быть getting used для этих....

  • Паскаль, без подчеркивания.
  • Старайтесь избегать сокращений.
  • Участники должны отличаться более чем в случае использоваться без учета регистра таких как Visual Basic.NET.

Почему: это соглашение согласовано с .NET Framework и легко читать. как

public int RecordId

ссылка: Стандарты NET-программирования и соглашения об именах

также проверьте это: Общие соглашения об именах

Ответ 5

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

Например:

public class Foo { /* ... */ }

public class Bar
{
    public Foo MyFoo { get; set; }
    // ...
}