Несколько вопросов о соглашении о присвоении имен C#

необходимо что в этом классе ?, # Не используйте префикс для переменных-членов (, m, s_ и т. Д.). Если вы хотите # различать локальные переменные и переменные-члены, вы должны использовать «this». в C # и «Я». в VB.NET.

Это весьма спорно. Префикс помогает intellisense: вы помещаете префикс char и получаете список только локальных полей частного экземпляра. С этим. вы получите полный список, который состоит из методов, полей, свойств, событий и т. д.

Рассмотрим также следующий пример:

private int _count; 
private int total; 
private decimal price; 

public MyClass(int count, int total, decimal price) 
{ 
    _count = count;     // correct 
    this.total = total; // correct 
    price = price;      // wrong! you forgot this. qualifier 
} 

1) Ключевое слово private не является обязательным. Я очень сомневаюсь, что Microsoft когда-либо изменит видимость полей по умолчанию, поскольку это будет серьезное критическое изменение (не говоря уже о глупом). Пропуск ключевого слова private - это просто вопрос личного вкуса.

2) Не используйте «кричащие» константы - следуйте соглашению структуры и используйте регистр паскалей (например, ThisIsAConstant ] предпочтительнее THIS_IS_A_CONSTANT).

1) Я предпочитаю использовать private, просто чтобы быть явным, но я думаю, что в этом нет необходимости

2) Это правда, Microsoft не рекомендует использовать заглавные буквы для констант.

Гайдлайны соглашения Microsoft об именах для членов типов можно найти здесь

Я сомневаюсь, что Microsoft когда-либо изменит значение по умолчанию поведение переменных-членов C #. Я бы объявил частными вещи, которые вы хотите сделать частными, и явно объявил бы вещи общедоступными, только для ясности, если ничего другого.

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

private не является обязательным, но требуется дополнительный ввод. Мне нравится пропускать это.

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

Возможно, вас заинтересуют рекомендации Microsoft по проектированию для разработчиков библиотек классов

Также частные имена полей должны быть в верблюжьем регистре, необязательно с префиксом _ или m_:

    private int count;
or
    private string _name;
or
    private decimal m_price;

Вас также могут заинтересовать Собственные правила внутреннего кодирования Microsoft для .NET Framework, как , как показал Брэд Абрамс в его блоге :

Следуйте всем рекомендациям по проектированию .NET Framework как для внутренних, так и для внешних участников. Основные из них:

• Не использовать венгерскую нотацию
• Не использовать префикс для переменных-членов (, m , s_ и т. Д.). Если вы хотите различать
• локальные переменные и переменные-члены, вы должны использовать «this». в C # и «Я». в VB.NET.
• Использовать camelCasing для переменных-членов
• Использовать camelCasing для параметров
• Использовать camelCasing для локальных переменных
• Использовать PascalCasing для имен функций, свойств, событий и классов
• Используйте префикс для имен интерфейсов с «I»
• Не используйте префиксы для перечислений, классов, или делегаты с любой буквой

Вот бесплатная электронная книга с рекомендациями по кодированию на C # и VB .net, она очень хороша

Ссылка на загрузку электронной книги

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

Используйте регистр Паскаля в именах полей.

Из Руководство разработчика .NET Framework. Имена членов типа

Используйте регистр Паскаля для всех имена членов, типов и пространств имен состоящий из нескольких слов.

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

Из Руководство разработчика .NET Framework. Соглашения о заглавных буквах

Обратите внимание на подразумеваемый стандарт Pascal регистр в именах констант.

ОБЯЗАТЕЛЬНО используйте константные поля для констант это никогда не изменится.

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

 публичная структура Int32 {
 общедоступная константа int MaxValue = 0x7fffffff;
 public const int MinValue = unchecked ((int) 0x80000000);
}

Из Руководства по разработке фреймворка: Соглашения, идиомы и шаблоны для многоразовых библиотек .NET, второе издание, стр. 161

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

Лично Мне бы очень понравилось, если бы константы были ALL_CAPS, как в некоторых других языках ... Я думаю, что это быстрый и простой способ определить константы. Тем не менее, поскольку в фреймворк UsePascalCasing встроены другие константы, вам тоже следует. Последовательность очень важна.

Что касается «Паскаль против верблюда», вы сталкиваетесь с той же проблемой. Если бы вы просто программировали самостоятельно, с нуля, вы могли бы делать все, что захотите. Но поскольку вы используете уже существующий фреймворк, для единообразия вам следует эмулировать тот же стиль. Кроме того, как только вы к этому привыкнете, вы, вероятно, обнаружите, что соблюдение того же набора правил действительно поможет, потому что вы сразу узнаете, что что-то является параметром или локальной переменной (camelCasing), а не свойством или константой (PascalCasing). .

s быстрый и простой способ найти константы. Тем не менее, поскольку в фреймворк UsePascalCasing встроены другие константы, вам тоже следует. Последовательность очень важна.

Что касается «Паскаль против Camel», вы сталкиваетесь с той же проблемой. Если бы вы просто программировали самостоятельно, с нуля, вы могли бы делать все, что захотите. Но поскольку вы используете уже существующий фреймворк, для единообразия вам следует эмулировать тот же стиль. Кроме того, как только вы к этому привыкнете, вы, вероятно, обнаружите, что соблюдение того же набора правил действительно поможет, потому что вы сразу узнаете, что что-то является параметром или локальной переменной (camelCasing), а не свойством или константой (PascalCasing). .

s быстрый и простой способ найти константы. Тем не менее, поскольку в фреймворк UsePascalCasing встроены другие константы, вам тоже следует. Последовательность очень важна.

Что касается «Паскаль против верблюда», вы сталкиваетесь с той же проблемой. Если бы вы просто программировали самостоятельно, с нуля, вы могли бы делать все, что захотите. Но поскольку вы используете уже существующий фреймворк, для единообразия вам следует эмулировать тот же стиль. Кроме того, как только вы привыкнете к этому, вы, вероятно, обнаружите, что соблюдение того же набора правил действительно поможет, потому что вы сразу узнаете, что что-то является параметром или локальной переменной (camelCasing), а не свойством или константой (PascalCasing). .

Последовательность очень важна.

Что касается «Паскаль против верблюда», вы сталкиваетесь с той же проблемой. Если бы вы просто программировали самостоятельно, с нуля, вы могли бы делать все, что захотите. Но поскольку вы используете уже существующий фреймворк, для единообразия вам следует эмулировать тот же стиль. Кроме того, как только вы привыкнете к этому, вы, вероятно, обнаружите, что соблюдение того же набора правил действительно поможет, потому что вы сразу узнаете, что что-то является параметром или локальной переменной (camelCasing), а не свойством или константой (PascalCasing). .

Последовательность очень важна.

Что касается «Паскаль против Camel», вы сталкиваетесь с той же проблемой. Если бы вы просто программировали самостоятельно, с нуля, вы могли бы делать все, что захотите. Но поскольку вы используете уже существующий фреймворк, для единообразия вам следует эмулировать тот же стиль. Кроме того, как только вы к этому привыкнете, вы, вероятно, обнаружите, что соблюдение того же набора правил действительно поможет, потому что вы сразу узнаете, что что-то является параметром или локальной переменной (camelCasing), а не свойством или константой (PascalCasing). .

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

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

private не является обязательным, поэтому вы можете пропустить его.

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

Не отвечать на ваш вопрос напрямую, но возможно, вас заинтересует Microsoft StyleCop . Это инструмент для анализа исходного кода с точки зрения правил стиля и согласованности. По умолчанию он налагает рекомендации Microsoft по стилю.

In C# visibility defaults to the most limited visibility possible. Without a modifier:

• non-inner classes are internal
• inner classes are private
• class members are private

Because it's a good idea to limit visibility as much as possible anyway, I try to always leave off the modifier where the default visibility is all I need. This makes those members that aren't the default more obvious, which helps keep me attentive to whether they really need to be that visible.

For constants, my preference would be to put them in their own class(es) so that the ClassName.ConstantName format makes it obvious what they are.

In general I follow Microsoft's Design Guidelines for Developing Class Libraries.