Cómo nombrar mejor los campos y las propiedades

Question

Microsoft says los campos y las propiedades deben diferir por algo más que casos. Entonces, si realmente representan la misma idea, ¿cómo deberían ser diferentes?

Aquí está el ejemplo de Microsoft de lo que no se debe hacer:

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

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

Ellos no dan ninguna orientación sobre cómo debe mirar. ¿Qué hacen la mayoría de los desarrolladores?

Answer 1

No, Microsoft dice miembros visibles públicamente deben diferir en más de un solo caso:

Esta regla solo se activa en miembros visibles públicamente.

(Eso incluye a los miembros protegidos, ya que son visibles para las clases derivadas.)

Así que esto está muy bien:

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

Mi regla personal es no permitir que cualquier cosa otros campos privados de todos modos , en ese punto no es un problema

¿Realmente necesita campos protegidos? ¿Qué hay de hacer que la propiedad tenga un setter protegido si quiere poder mutarlo desde clases derivadas?

Answer 2

me gustan:

protected string _Bar; 

public string Bar   
{    
    get { return _Bar; }   
}  

Answer 3

que la mayoría de los desarrolladores prefijo de variables miembro con subrayan este modo:

protected string _bar; 

Answer 4

Esto puede hacer que algunos desarrolladores se lancen con disgusto, pero me gusta nombrar convenciones que me permitan distinguir las variables de los miembros de los locales de un vistazo.

Por lo tanto, hago a menudo algo como:

public class Foo 
{ 
    protected string _bar; 

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

... o ...

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

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

Answer 5

personalmente me gusta este libro de Balena:

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

Personalmente, hago lo siguiente:

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

Originalmente solía usar _ o m_ como un prefijo para todos mis campos hasta que comencé a buscar un montón de código .NET de Microsoft a través de Reflector. Microsoft también usa el paradigma s_ y m_, y me gusta. Hace que sea fácil saber exactamente qué es un campo cuando estás leyendo el cuerpo del código de una función. No tengo que señalar nada y esperar a que aparezca una información sobre herramientas o algo así. Sé si algo es estático o instancia simplemente por su prefijo de campo.

Answer 7

Depende de usted o de la norma de codificación de su compañía/organización.Pero la mayoría de los programadores utilizar camelCasing o subrayan + camelCasing en Campos y PascalCasing sobre las propiedades como:

public class Foo  
{   
    protected string _bar; 

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