Я видел два общих подхода для стандартов кодирования для частных переменных-членов:
class Foo
{
private int _i;
private string _id;
}
и
class Foo
{
private int m_i;
private string m_id;
}
Я считаю, что последнее исходит из С++. Кроме того, многие люди задают тип перед переменной-членом (например, double m_dVal), чтобы указать, что это не константная переменная-член типа double?
Каковы соглашения в С#?
Помимо двух, которые вы упоминаете, в С# очень часто нет префикса для частных членов.
class Foo
{
private int i;
private string id;
}
Это то, что я использую, а также то, что рекомендуется в Внутренние правила именования Microsoft.
Как отмечено Брэд Абрамс: внутренние правила кодирования:
Не используйте префикс для члена переменные (
_,m_,s_и т.д.). если ты хотят различать локальные и переменные-члены, которые вы должны использовать "this." в С# и "Me." в VB.NET.
Я предпочитаю использовать ваш первый пример или авто-свойства, подобные этому, и избегать личных полей, определенных в вашем классе:
public String MyString { get; set; }
Используйте фрагмент prop, чтобы сделать эти ДЕЙСТВИТЕЛЬНО быстрыми.
Как я помню из чтения Framework Design Guidelines, для частных переменных-членов нет стандартного соглашения, за исключением того, что не следует использовать венгерский но не следует использовать первую букву имени переменной (используйте Camel-обсадку). В книге есть цитаты, которые поддерживают оба ваших примера, а также не используют какой-либо префикс.
Лично я предпочитаю префикс "m_".
Я думаю, что важным принципом здесь является то, что вы последовательны. Используйте префикс "_" или "m", если это то, что вам нравится, и оно согласуется с остальной частью кода, с которым вы работаете. Что бы вы ни выбрали, придерживайтесь его и будьте последовательны.
Общее руководство от Microsoft здесь:
http://msdn.microsoft.com/en-us/library/ms229002.aspx
Автоматические свойства в С# велики, и я использую тогда, когда могу, но есть случаи, когда они не работают для меня, например, при выполнении проверки типов или значений по установленному методу.
В общем: используйте оболочку верблюда и не префикс своего имени ничем, например, подчеркиванием или префиксом типа.
public int Age {get; set;}
или
private int age;
public int Age
{
get { return age; }
set
{
if(value < 0)
throw new InvalidOperationException("Age > 0");
age = value;
}
}
Я лично всегда использовал ваш первый пример:
public class Foo
{
private int _i;
private string _id;
}
Фактически, это то, что использует вся моя команда. Кроме того, упомянутый вами m_dVal известен как венгерская нотация, вот Wikipedia Entry. Венгерская нотация на самом деле противоречит стандартам кодирования наших команд, поэтому я никогда не использую ее.
Лучше всего использовать то, что уже используется в проекте. Если вы начинаете новый проект, используйте то, что чаще всего используется в компании.
Я предпочитаю подчеркивание как префикс для частных неконтактных полей без чтения. Зачем? Причины: 1. Просто глядя на переменную, я могу различать полевую и локальную/переменную параметра. Использование "этого". для всех полей не вариант - его дольше. 2. Существует неоднозначность между параметром и полем:
class Foo
{
private int id;
public Foo(int id)
{
id = id; //Will compile and work fine. But field will not be initialized.
}
}
Я склоняюсь к первому соглашению, простому подчеркиванию. Я также не указываю тип в имени, потому что у меня Intellisense говорит мне, что это (я знаю, это может быть костыль).
Лучше всего проконсультироваться со своими коллегами или партнерами по проектам и просто принять решение о соглашении, некоторые из них являются произвольными.
Я предпочитаю не использовать какой-либо префикс вообще для переменных-членов. Для тех, кто объявлен вне метода, я использую "this.memberVariableName", чтобы отличать их от объявленных внутри метода.
Идентификаторы С++, начинающиеся с _, считаются плохой практикой, их следует оставить для внутреннего использования. Я думаю, именно поэтому префиксация имени переменной с помощью _ иногда считается плохой практикой в С#... хотя нет причин, по которым вы не можете этого сделать, поскольку все внутренние компоненты .NET инкапсулированы должным образом, в отличие от C/С++ стандартных библиотек.