2009-04-13 4 views
25

Я видел два общих подхода к стандартам кодирования для частных переменных-членов:C# стандарты кодирования для частных переменных членов

class Foo 
{ 
    private int _i; 
    private string _id;  
} 

и

class Foo 
{ 
    private int m_i; 
    private string m_id; 
} 

Я считаю, что последний приходит из C++. Кроме того, многие люди указывают тип перед переменной-членом (например, double m_dVal), чтобы указать, что это не постоянная переменная-член типа double?

Каковы соглашения в C#?

+0

@Andrew Hare НЕ точный дубликат, поскольку я прошу об общем случае, а не только m_. thx для указания ссылки, хотя ... – 2009-04-13 13:16:40

+3

Это «dupe» было закрыто как S & A. Этот вопрос действительно (и ответ driis был очень полезным, я мог бы добавить). –

ответ

10

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

public String MyString { get; set; } 

Используйте prop фрагмент кода, чтобы сделать это очень быстро.

+2

Работает, за исключением того, что вы не можете сделать авто свойства только для чтения ... ага, может быть, я буду искать его в C# 5.0. –

+9

Вы можете сделать их «только для чтения», сделав набор приватным или защищенным: public String MyString {get; частный набор; } –

+1

+1 Я не знал об этом фрагменте, спасибо! – wsanville

55

Помимо двух вы упомянули, очень часто в C# нет префикса для частных членов.

class Foo 
{ 
    private int i; 
    private string id; 
} 

Это то, что я использую, а также то, что рекомендуется в Microsoft's internal naming guidelines.

+10

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

+22

Я предпочитаю знак подчеркивания, потому что мне нравится знание области переменной, просто глядя на имя –

+1

. Я также всегда использую префикс подчеркивания для полей поддержки свойств, поскольку его легко сделать ошибку и получить ... stackoverflow hur;) – meandmycode

7

Как я помню из чтения Framework Design Guidelines, для частных переменных-членов не существует условного соглашения, за исключением того, что нельзя использовать венгерскую нотацию, и нельзя использовать первую букву имени переменной (используйте Camel-casing). В книге есть цитаты, которые поддерживают оба ваших примера, а также не используют какой-либо префикс.

Лично я предпочитаю префикс «m_».

13

Как отметил Brad Abrams: internal coding guidelines:

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

+2

Что такое (действительно, действительно!) Глупое руководство при применении к VB: VB не различает случай идентификаторов, поэтому это руководство просто * делает не работает * (он не может различать свойства и поля поддержки)! Невероятный. Ну, он все же может быть применен к C#. Справедливо. –

+21

@ Konrad Radolph: Похоже, у них есть неявная * внутренняя * рекомендация: не используйте VB :) –

+1

Я думаю, что они должны. Мне жаль, что у меня не было ссылки, но я прочитал рекомендацию о том, что этот случай не будет использоваться в качестве единственного отличительного фактора в C# для поддержания совместимости с interopt. –

1

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

Лучше всего проверить со своими коллегами или товарищами по команде, и просто принять решение по конвенции, некоторые из них являются произвольными.

1

Я предпочитаю не использовать какой-либо префикс вообще для переменных-членов. Для тех, кто объявлен вне метода, я использую «this.memberVariableName», чтобы отличить их от объявленных внутри метода.

6

Общее руководство от Microsoft здесь:

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

Автоматические свойства в C# являются большими, и я использует тогда, когда я могу, но бывают случаи, когда они не работают для меня, например, при выполнении типа или проверка значения по установленному методу.

В целом: используйте кожух верблюда и не префикс своего имени ничем, как подчеркивание или префикс типа.

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; 
    } 
} 
+2

Не поклонник метательных исключений - это свойство getter/seters. Но это другая возможность червей :) –

+0

Я согласен, а не то, что я даже нечасто делаю. Подробнее для иллюстрации. Согласились, другие могут о-черви. – andleer

7

Я думаю, что важным принципом здесь является то, что вы последовательны. Используйте префикс «_» или «m», если это то, что вам нравится, и оно согласуется с остальной частью кода, с которым вы работаете. Что бы вы ни выбрали, придерживайтесь его и будьте последовательны.

+4

аминь. Согласование является единственным стандартом, который требуется. – gbjbaanb

3

Лучше всего использовать то, что уже используется в проекте. Если вы начинаете новый проект, используйте то, что чаще всего используется в компании.

+10

Если вы начинаете новую компанию, бросьте монету. :) – ibz

0

Идентификаторы C++, начинающиеся с _, считаются плохой практикой, их следует оставить для внутреннего использования. Я думаю, именно поэтому префиксация имени переменной с помощью _ иногда считается плохой практикой в ​​C# ... хотя нет причин, по которым вы не можете этого сделать, поскольку все внутренние компоненты .NET инкапсулированы должным образом, в отличие от C/C++ стандартных библиотек.

+0

В C++ мне нравится _ как суффикс для переменных-членов (таким образом, исключая проблему внутреннего использования) – User

+0

Да, это запрещено стандартами. Я использую «m» без подчеркивания - несмотря на общепринятую мудрость (ее легче читать, как только вы преодолеете свое предвзятое восприятие и еще одно, чтобы запутать новичков). – jheriko

3

Я предпочитаю символ подчеркивания как префикс для частных неконтактных полей без чтения. Зачем? Причины: 1. Просто взглянув на переменную, я могу различать поле & local/parameter variable. Использование «этого». для всех полей не вариант - его дольше. 2. Существует неоднозначность между параметром и поля:

class Foo 
{ 
    private int id; 
    public Foo(int id) 
    { 
    id = id; //Will compile and work fine. But field will not be initialized. 
    } 
} 
+0

Этот конкретный сценарий будет генерировать предупреждение. –

4

лично я всегда использовал свой первый пример:

public class Foo 
    { 
     private int _i; 
     private string _id; 
    } 

На самом деле, это то, что использует всю мою команду. Кроме того, тот, который вы упоминали m_dVal, известен как венгерская нотация, вот Wikipedia Entry. Венгерская нотация на самом деле противоречит стандартам кодирования наших команд, поэтому я никогда не использую ее.

Смежные вопросы