Недавно я начал использовать ReSharper, который является фантастическим инструментом. Сегодня я столкнулся с правилом имен для статических полей, а именно с префиксом с подчеркиванием, т.е.
private static string _myString;
В руководствах Microsoft не говорится о частных полях, они касаются только видимых на публике членов.
Общие соглашения: camelCase, _camelCase и даже иногда похмелье из С++/MFC m_camelCase.
Если вы используете camelCase без префикса, поля поддержки свойств будут отличаться от имени свойства только в случае, что не является проблемой на С#, но не будет работать на языке, не учитывающем регистр, например VB.NET.
Так много людей, включая меня, любят использовать префикс подчеркивания, чтобы одни и те же стандарты могли использоваться на всех языках. По моему опыту, подчеркивание гораздо более распространено, чем m_.
В соответствии с MSDN используйте Паскаль Кейс для статических полей. Я всегда хихикаю, когда MSDN и StyleCop противоречат друг другу:).
Итак, если вы следуете стандартам MSDN, правильный путь:
private static string MyString;
На самом деле это стиль для частного поля, статического или нет. (По крайней мере, в ReSharper)
В соответствии с StyleCop (и с настройками по умолчанию) правильный способ назвать большинство полей (как указано ниже) имеет строчный регистр буква в начале.
SA1306: FieldNamesMustBeginWithLowerCaseLetter
... Имена полей и переменных должны начинаться с буквы в нижнем регистре, если поле не является общедоступным или внутренним, const или не-частным и readonly. В этих случаях поле должно начинаться с буквы верхнего регистра.
См. также SA1309: FieldNamesMustNotBeginWithUnderscore.
Проблема, с которой я столкнулась с руководством MSDN (используйте случай Pascal), заключается в том, что она не приводит к различию между частной статической переменной и общедоступным (нестатическим) свойством. Такая же проблема возникла бы для статических свойств - никакого различия между статическими и нестатическими.
Возможно, это преднамеренно?
Одним из путей этого было бы использовать тот же стандарт для статики, что и для нестатики, но всегда квалифицировать использование статики путем префикса с именем класса. Это может быть несколько дополнительных символов для ввода, но это делает код более удобочитаемым. Например:
public class Employee
{
private static Int32 thresholdPercentage = 5;
public static String TooMuchMessage = "Unacceptable pay rise - sorry!";
private Decimal _salary = 0.0m;
public void RaiseSalary(Int32 raiseAmountPercentage)
{
if (raiseAmountPercentage > Employee.thresholdPercentage)
throw new ApplicationException(Employee.TooMuchMessage);
_salary *= 1 + (raiseAmountPercentage / 100);
return;
}
}
Соглашение - это то, о чем говорят ваши стандарты кодирования вашей компании.
1 - Не существует стандартного правила для имен переменных. Существуют требования к компилятору С# для разрешенных и не разрешенных (т.е. Не могут начинаться с числа), но правила стиля программирования на языке, как правило, остаются за программистами/организациями. ReSharper имеет заранее определенные правила стиля; однако они просто устанавливаются как значения по умолчанию в соглашении по конфигурации и могут быть изменены.
2 - Вы можете взглянуть на эту статью в Википедии, чтобы увидеть историю Camel Casing.
Для статических полей я решил установить StaticUpperCamelCase (например, StaticPersonCache), поскольку он явно отличает его от переменной экземпляра. Это включает в себя частные статические поля, а также статические поля с другими модификаторами видимости.
Для статических переменных мне нечего беспокоиться о том, чтобы показать публичность/закрытость видимости через имя, а не указывать, как переменная работает между экземплярами. Кроме того, поскольку нет (и действительно не должно быть) многих Статических переменных, модификатор типа "Хугариан" не применяется часто.
Аналогично, для статических переменных потока ([ThreadStatic] или ThreadLocal) конвенция, которую я использую, - TS_UpperCamelCase (например. TS_Random). И снова этот "разрыв" с нормами передает очень важную информацию, которую другие разработчики могут не увидеть на первый взгляд. Таким образом, имя используется как предостерегающий флаг.
Я использую ReSharper и соответствующим образом скорректировал предупреждения/подсказки; большинство других соглашений об именах сохраняются в настройках ReSharper по умолчанию.
Мой выбор таких "нестандартных" условностей для статических/поточно-статических полей (примечание: Microsoft использует TS_ в некотором коде в библиотеке .NET), потому что я столкнулся с более чем "quirk" из-за неправильной идентификации переменных Static/ThreadStatic/Instance: это намного сложнее сделать с StaticX, TS_X, _x.