¿Qué es una convención de nomenclatura correcta para CLS para campos protegidos?

Question

Estoy desarrollando una biblioteca de tipos compatibles con CLS y tengo una clase dentro de It, que contiene campos y propiedades privadas, protegidas y públicas. Uso el símbolo de subrayado (_) como prefijo para campos privados o protegidos y la primera letra pequeña para distinguir sus propiedades de los mismos nombres. Se ve tan:

class SomeClass 
{ 
private int _age; //Here is OK 

public int Age { get { return this._get; } } 
} 

Pero cuando trato de utilizar campos protegidos que chocan con el siguiente problema:

class SomeClass 
{ 
protected int _age; //Here is NOT CLS-compliant (because of _ can't be the first symbol of identifier) 

public int Age { get { return this._get; } } 
} 

Entonces traté de hacerlo de tal manera:

class SomeClass 
{ 
protected int age; //Here is NOT CLS-compliant (because of age and Age differ only in one symbol) 

public int Age { get { return this._get; } } 
} 

favor , dime, ¿cuál es la notación o convención que cumple con CLS entre los desarrolladores para tales casos? ¿Tengo que usar prefijos en estilo C como l_age?

Answer 1

Aquí hay una versión más correcta, la OMI:

private int _age; 
public int Age { 
    get { return this._age ; } 
    protected set { this._age = value; } 
} 

o simplemente:

public int Age { get; protected set; } 

Si encapsular correctamente, entonces no importa lo que el campo se llama, como se nada fuera de ese tipo puede verlo.

---

En los comentarios, a continuación, se planteó la cuestión de los acontecimientos, con el ejemplo:

protected EventHandler<StateChangedEventArgs> _stateChanged; 
public event EventHandler<StateChangedEventArgs> StateChanged 
{ 
    add { lock (this.StateChanged) { this._stateChanged += value; } } 
    remove { lock (this.StateChanged) { this._stateChanged -= value; } } 
} 

Aquí vuelvo a afirmar que no hay ninguna razón de este campo para ser protegida; el evento no pertenece a la clase derivada. Dispone de 2 operaciones sensibles que puede que desee realizar:

1. distribuir el evento
2. suscribirse/darse de baja en el caso

El primero se debe hacer a través del patrón de On*; este último solo debe usar los accesadores regulares (de lo contrario, viola el bloqueo). Además, incluso si asumimos que lock(this.StateChanged) es un error (que sería un muy, muy malo para su uso como el objeto de bloqueo -Es no funcionaría en absoluto), cabe destacar que en C# 4.0, el compilador tiene una estrategia de bloqueo mucho más eficiente incorporada (que usa Interlocked en lugar de Monitor) cuando se escribe un evento "similar a un campo" (es decir, no explícita add/remove). En consecuencia, el enfoque preferido aquí sería:

public event EventHandler<StateChangedEventArgs> StateChanged; 
protected virtual void OnStateChanged(StateChangedEventArgs args) { 
    var snapshot = StateChanged; // avoid thread-race condition 
    if(snapshot != null) shapshot(this, args); 
} 

y ... ¡eso es todo!

• si la subclase quiere suscribirse/darse de baja (no es ideal, pero MEH) que sólo utiliza StateChanged += y StateChanged -=
• si la subclase quiere distribuir el evento, llama OnStateChanged(...)
• si la subclase quiere modificar la lógica de eventos, se añade un override a

sin necesidad de ningún campo no privados.

Answer 2

para respaldar la respuesta de Marc, la orientación sobre Field Design de Microsoft afirma: campos

públicas y protegidas no hacen versión bien y no están protegidos por las exigencias de seguridad de acceso del código. En lugar de usar campos públicamente visibles, use campos privados y exhíbalos a través de las propiedades.

Esta es probablemente la razón por que no encontrará en cualquier orientación útil sobre los nombres de ellos (de hecho, el naming guidelines simplemente apunte hacia atrás en la página Diseño Campo).