Как лучше всего назвать поля и свойства

Question

Microsoft говорит, что поля и свойства должны отличаться больше, чем просто случай. Итак, если они действительно представляют одну и ту же идею, как они должны отличаться?

Вот пример Microsoft того, чего не следует делать:

using System;
namespace NamingLibrary
{    
    public class Foo    // IdentifiersShouldDifferByMoreThanCase    
    {        
        protected string bar;

        public string Bar        
        {            
            get { return bar; }        
        }    
    }
}

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

Answer 1

Нет, Microsoft говорит, публично видимые участники должны отличаться больше, чем просто случай:

Это правило действует только для публично видимых участников.

(Это включает защищенные члены, так как они видимы для производных классов.)

Так что это нормально:

public class Foo
{
    private string bar;
    public string Bar { get { return bar; } }
}

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

Вам действительно нужны защищенные поля? Как насчет того, чтобы свойство имело защищенный установщик, если вы хотите иметь возможность изменять его из производных классов?

Answer 2

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

Итак, я часто делаю что-то вроде:

public class Foo
{
    protected string _bar;

    public string Bar
    {
        get { return _bar; }
    }
}

... или ...

public class Foo
{
    protected string mBar;    // 'm' for member

    public string Bar
    {
        get { return mBar; }
    }
}

Answer 3

Это зависит от стандарта кодирования, используемого вами или вашей компанией. Но большинство программистов используют camelCasing или underscore + camelCasing для полей и PascalCasing для таких свойств, как:

public class Foo    
{         
    protected string _bar; 

    public string Bar         
    {             
        get { return _bar; }         
    }     
} 

Answer 4

Я лично делаю следующее:

class SomeClass
{
    private static string s_foo;   // s_ prefix for static class fields
    private string m_bar;          // m_ prefix for instance class fields

    public static string Foo
    {
        get { return s_foo; }
    }

    public string Bar
    {
        get { return m_bar; }
    }
}

Изначально я использовал просто _ или m_ в качестве префикса для всех моих полей, пока не начал копаться в большом количестве кода Microsoft .NET через Reflector. Microsoft также использует парадигму s_ и m_, и мне это нравится. Это позволяет легко точно знать, что такое поле, когда вы читаете код тела функции. Мне не нужно ничего указывать и ждать появления всплывающей подсказки или чего-то в этом роде. Я знаю, является ли что-то статическим или экземпляром просто по префиксу поля.

Answer 5

Мне лично нравится эта книга Балены:

http://www.amazon.com/Practical-Guidelines-Practices-Developers-Pro-Developer/dp/0735621721/ref=sr_1_1?ie=UTF8&s=books&qid=1265845146&sr=8-1

Answer 6

Подумайте, что большинство разработчиков префиксируют переменные-члены с подчеркиванием следующим образом:

protected string _bar;

Answer 7

Мне нравится:

protected string _Bar;

public string Bar        
{            
    get { return _Bar; }        
}