Come meglio denominare campi e proprietà

Question

Microsoft says campi e proprietà devono differire da più di un semplice caso. Quindi, se rappresentano veramente la stessa idea, come dovrebbero essere diversi?

Ecco l'esempio di Microsoft di cosa non fare:

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

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

danno alcuna indicazione su come questo dovrebbe apparire. Cosa fanno la maggior parte degli sviluppatori?

Answer 1

No, Microsoft dice membri visibili pubblicamente devono differire di più di un semplice caso:

Questa regola viene attivata solo sui membri visibili pubblicamente.

(Che include membri protetti, in quanto sono visibili a classi derivate.)

Quindi questo va bene:

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

mia regola personale non è quello di introdurre nulla campi privati ​​in ogni caso a quel punto non è un problema.

Avete davvero bisogno di campi protetti? Che ne dici di rendere la proprietà un setter protetto se vuoi essere in grado di mutarlo dalle classi derivate?

Answer 2

mi piace:

protected string _Bar; 

public string Bar   
{    
    get { return _Bar; }   
}  

Answer 3

che la maggior parte sviluppatori prefisso variabili membro con sottolineano in questo modo:

protected string _bar; 

Answer 4

Questo potrebbe far scattare alcuni sviluppatori là fuori con disgusto, ma mi piacciono le convenzioni di denominazione che mi consentono di distinguere le variabili membro dai locali a colpo d'occhio.

Quindi, faccio spesso qualcosa di simile:

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, come questo libro di 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

Io personalmente faccio quanto segue:

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

Originariamente utilizzavo _ o m_ come prefisso per tutti i miei campi fino a quando non ho iniziato a scavare molto codice Microsoft .NET tramite Reflector. Microsoft usa anche il paradigma s_ e m_, e mi piace un po '. Rende facile sapere esattamente che cosa è un campo quando stai leggendo il codice del corpo di una funzione. Non devo indicare nulla e aspettare che compaia un suggerimento o qualcosa del genere. So se qualcosa è statico o istanza semplicemente dal suo prefisso di campo.

Answer 7

Dipende dallo standard di codifica dell'azienda o dell'organizzazione.Ma la maggior parte dei programmatori utilizzano camelCasing o sottolineano + camelCasing sui Campi e PascalCasing su Case simili:

public class Foo  
{   
    protected string _bar; 

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