В соглашениях об именах С# для переменных-членов

Ответ 1

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

Я бы просто рекомендовал следующие Соглашения об именах для С#, предоставленные MSDN, а также Общие соглашения об именах, предоставляемые MSDN.

В частности, они говорят об свойствах:

Использовать свойства имени с помощью существительного, существительного фразой или прилагательным.

Существительные фразы или прилагательные подходит для свойств, потому что свойства сохраняют данные.

Не используйте свойства, соответствующие имена методов Get.

Например, не называйте свойство EmployeeRecord, а также имя метода GetEmployeeRecord. Разработчики не будут знать, какой член использовать для достижения их задача программирования.

Указать имя Boolean properties с утвердительная фраза (CanSeek вместо CantSeek). При желании вы также можете префикс Булевы свойства с Is, Может, или имеет, но только там, где он добавляет значение.

Подумайте о том, чтобы дать свойство имя как его тип.

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

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

Ответ 2

В большинстве случаев переменные уровня класса добавляются с подчеркиванием. Поэтому myVariable фактически _myVariable. Многим людям не нравится выдавать имя одному персонажу, потому что слишком легко совершить ошибку.

Нет ничего плохого в том, чтобы просто делать myVariable и MyVariable. Это просто конвенция, и если все последуют за ней, то она, вероятно, будет работать нормально.

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

public String MyVariable
{
   get;
   private set;
}

Ответ 3

Обычно я всегда вижу частных членов с ведущим _. (предполагая, что это не свойство auto)

private string _customerName;
public string CustomerName
{
    get{return _customerName;}
    set{_customerName = value;}
}

Конечно, окончательный вердикт - это соглашение вашей команды (предполагая, что вы не выполняете проект одинокого волка или не работаете с полными идиотами)

Ответ 4

Я брошу свою шляпу в кольцо с тем, что я всегда использовал

class ClassName //Classes are PascalCase
{
    public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
    {
       _myProperty = myPropriety;
    }
    public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
    {
        int sampleVar; //local variables are camelCase
    }
    public int MyProperty { get { return _myProperty; } } // Properties are PascalCase

    private int _myProperty; // Private fields are camelCase and start with a _

Ответ 5

Вот окончательная рекомендация от Microsoft.

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

Наслаждайтесь!

Ответ 6

Нет ничего плохого в этих соглашениях об именах.

Версия свойства на самом деле является рекомендуемым форматом в соответствии с руководящими принципами проектирования .Net.

Полевая декларация также соответствует руководящим принципам структуры, поскольку она camelCased. Это иногда немного религиозная война относительно того, должна ли переменная быть префикс с _ или m_. Это вопрос, который нужно решить в вашей группе.

..........................

• http://msdn.microsoft.com/en-us/library/ms229012.aspx

Ответ 7

Одна из причин, по которой я могу думать, что не использовать случай для дифференциации публичных и частных членов, заключается в том, что Visual Studio Intellisense будет сортировать обоих членов рядом друг с другом, поэтому вы можете использовать неверный, не заметив.

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

Ответ 8

Что бы вы ни выбрали для обозначения именования, будьте последовательны. Тогда, по крайней мере, когда вы вернетесь к коду через шесть месяцев или когда кто-то новый посмотрит на него в первый раз, они смогут разобраться, что.

Ответ 9

Будьте осторожны с этим сценарием:

public class MyClass {
    public int Foo { get; private set; }

    public MyClass(int foo) {
        // oops, setting the parameter to itself, not the property
        foo = foo;
    }
}

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

Ответ 10

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

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

Выше сказано, что это не влияет на сценарий частного члена поддержки.

Ответ 11

Основная проблема с предложенным соглашением об именах - Intellisense будет использовать закрытую переменную над свойством. Во многих случаях это не проблема (на самом деле, как правило, хорошая вещь), но для тех немногих случаев, когда она существует, соглашение, разделяющее два имени, полезно. Мне нравится m_ для частных переменных-членов и c_ для частных статических переменных.

Ответ 12

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

Ответ 13

Два наиболее популярных соглашения, которые я вижу, представляют собой префикс частных переменных-членов с помощью _ или m_. Я лично предпочитаю m_-конвенцию, но пока это согласовано в проекте/команде, мне действительно все равно. Я не один, чтобы попасть в "религиозные войны":)

Ответ 14

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

В дополнение к соглашению Pascal/camelCase для публичных/частных членов я всегда выбираю имена переменных-членов, состоящие из 2 или более слов, а локальные имена переменных, состоящие из single строчное слово или даже буква.

public class MyCanvas : Canvas {
    public int CanvasId { get; private set; }
    private double canvasHeight; // member vars consist of 2+ words
    private double canvasWidth;

    public MyCanvas(int id) {
        CanvasId = id;
        double height = ...; // local vars consist of one word/letter
        canvasHeight = height;
    }
}

Это позволяет выбирать последовательные и значимые имена переменных без "смешных" префиксов, таких как _, а также различать локальные и переменные-члены.