cref - Pautas de nombres de campo C#?

remarks c#

Question

Voy a trabajar en un poco de código C # por mi cuenta, pero quiero asegurarme de seguir las convenciones de nomenclatura más ampliamente aceptadas en caso de que quiera atraer a otros desarrolladores, liberar mi código o vender mi código. En este momento estoy siguiendo la convención de nomenclatura que Microsoft ha establecido, ya que parecen ser los más aceptados. Lo único que no mencionan es nombrar campos privados. En su mayoría, los he visto nombrados en camelCase como campos protegidos, sin embargo, eso me presenta un problema ya que los nombres de los parámetros deberían estar en camelCase. Tome el siguiente constructor por ejemplo:

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

Ahora bien, si uso camelCase para los campos privados también existe un conflicto de nombres a menos que use "this" para acceder a los campos de la clase (lo que creo que va en contra de la mayoría de los estándares, sin mencionar que significa más tipeo). Una solución es dar al parámetro un nombre diferente, pero no tiene sentido lógico dar los mismos datos a 2 nombres diferentes. La única otra solución que conozco que era común en la codificación C ++ es darles a los miembros privados un guión bajo al principio (_camelCase). ¿Es esa solución comúnmente aceptada con la codificación C #? ¿Hay alguna otra solución a este problema (como usar solo propiedades (que usan PascalCase) para acceder a los campos, incluso en la misma clase)?

Answer 1

Como se mencionó, Microsoft Naming Guidelines dose no cubre los campos privados y los nombres de variables locales. Y no encuentra consistencia dentro de Microsoft. Si genera una clase o patrón Desechable en Visual Studio, creará algo así como

class MyClass : MyBaseClass, IMyInterface
{
    public event EventHandler MyEvent;
    int m_MyField = 1;
    int MyProperty {
        get {
            return m_MyField;
        }
        set {
            m_MyField = value;
        }
    }

    void MyMethod(int myParameter) {
        int _MyLocalVaraible = myParameter;
        MyProperty = _MyLocalVaraible;
        MyEvent(this, EventArgs.Empty);
    }
}

o

Class MyClass

    Private msClassVariable  As String = ""

    Private _classProperty As Integer = 0
    Property Readonly ClassProperty() As Integer
        Get
            Return _classProperty
        End Get
    End Property

    Sub New()

        Dim bLocalVariable As Boolean = False
        if _classProperty < 0 Then _classProperty = 0
        msClassVariable  = _classProperty.ToString()
        bLocalVariable = _classProperty > 0
    End Sub

End Class

Afortunadamente, Microsoft abrió cada vez más código, así que echemos un vistazo a sus repositorios, por ejemplo ASP.NET Core MVC

public MyClass(int value)
{
    this.value = value;
}

O .NET Core

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

Usted puede decir que no es en realidad Microsoft, sino .NET Foundation. Muy bien, echemos un vistazo a los repos de Microsoft :

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

Pero aquí está la antigua implementación de Microsoft de MVC

private T[] _array;

Por lo tanto, no hay ninguna práctica común o directriz oficial con respecto a la asignación de nombres de campos privados . Simplemente elija uno que prefiera y quédese con él.

Answer 2

Eche un vistazo a ReSharper. Subrayará todos los lugares donde sus nombres no confirman las pautas comunes, y puede personalizarlo. Además, por supuesto, hay montones y montones de otras mejoras de productividad.

Answer 3

En general, hay dos formas ampliamente usadas para nombrar campos (siempre usando camelCase ):

Usando un prefijo de subrayado

void F(String someValue) {
  _someValue = someValue;
}

Usando this. para acceder al campo y evitar conflictos de nombre

void F(String someValue) {
  this.someValue = someValue;
}

Personalmente prefiero lo posterior, pero usaré cualquier convención establecida por la organización para la que trabajo.

Answer 4

En nuestra tienda, comenzamos nuestro primer proyecto C # utilizando la guía sugerida de Microsoft para miembros privados, es decir,

camelCaseFieldName

Pero pronto nos encontramos con la confusión entre los miembros privados y los parámetros, y cambiamos a

_camelCaseFieldName

que ha funcionado mucho mejor para nosotros.

Un miembro privado por lo general tiene un estado que persiste fuera de una llamada a un método: el guión bajo tiende a recordarlo.

También tenga en cuenta que el uso de la sintaxis AutoVariable para las propiedades puede minimizar la necesidad de campos de respaldo privados, es decir,

public int PascalCaseFieldName { get; set;}

Para obtener un buen conjunto conciso de estándares que (en su mayoría) sigan las directrices de MS, consulte net-naming-conventions-and-programming-standards---best-practices

Answer 5

Hago esto; está más o menos en línea con MSDN.

private readonly MetricSeries zeroDimSeries;

Aquí hay un poco más de detalle: http://jerrytech.blogspot.com/2009/09/simple-c-naming-convention.html

Answer 6

He hecho mucho más con VB que C #, así que supongo que transfiero algunas prácticas (¿prejuicios?) De la primera a la segunda.

Me gusta que los campos privados de propiedades tengan un guión bajo principal, especialmente en C # debido a la distinción entre mayúsculas y minúsculas (¿quién lo idea?) Y prefijo las variables de módulo / clase con "m" para reforzar su alcance .

Si no te gusta, realmente no te va a gustar esto: generalmente también uso prefijos de tipo (excepto para los campos de propiedad) - "o" para Objeto, "s" para Cadena, "i" para Entero, etc. .

Realmente no puedo defender esto con un artículo revisado por pares o cualquier otra cosa, pero funciona para nosotros y significa que no nos hemos tropezado con la carcasa o la confusión de campo / parámetro.

Asi que ...

private IActionInvoker _actionInvoker;

Answer 7

La convención que utilizo para distinguir entre las variables privadas de clase y los parámetros del método es:

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}

Answer 8

Lo más importante es elegir un estándar y aferrarse a él. Consulte el estándar de codificación C # de IDesign en IDesign (es un enlace en el lado derecho). Es un gran documento que cubre cosas como pautas de nombres. Recomiendan usar camel case para las variables locales y los argumentos del método.

Answer 9

Siga las Pautas de nombres de Microsoft . Las pautas para el uso de campo indican que debe ser camelCase y no debe estar prefijado. Tenga en cuenta que la regla general no es prefijo; la regla específica no es el prefijo para distinguir entre campos estáticos y no estáticos.

No aplique un prefijo a nombres de campo o nombres de campos estáticos. Específicamente, no aplique un prefijo a un nombre de campo para distinguir entre campos estáticos y no estáticos. Por ejemplo, aplicar un prefijo g_ o s_ es incorrecto.

y (de las msdn.microsoft.com/en-us/library/ms229045.aspx )

No use guiones bajos, guiones ni ningún otro carácter no alfanumérico.

EDITAR : Notaré que los documentos no son específicos con respecto a los campos privados , pero indican que los campos protegidos deben ser camelCase solamente. Supongo que se puede deducir de esto que cualquier convención para campos privados es aceptable. Ciertamente, los campos estáticos públicos difieren de los protegidos (están en mayúscula). Mi opinión personal es que protected / private no son lo suficientemente diferentes en el alcance para garantizar una diferencia en la convención de nombres, especialmente porque todo lo que parece querer hacer es diferenciarlos de los parámetros. Es decir, si sigue las pautas para los campos protegidos, tendría que tratarlos de manera diferente a este respecto que los campos privados para distinguirlos de los parámetros. Utilizo this cuando me refiero a los miembros de la clase dentro de la clase para aclarar la distinción.

EDIT 2

Adopté la convención utilizada en mi trabajo actual, que es prefijar las variables de instancia privadas con un guión bajo y, en general, solo expongo las variables de instancia protegidas como propiedades usando PascalCase (típicamente autopropiedades). No era mi preferencia personal, pero es con la que me he sentido cómodo y probablemente seguiré hasta que surja algo mejor.

Answer 10

Siguiendo las convenciones de nomenclatura de Microsoft, los campos privados deben ir precedidos de un guión bajo.

Por ejemplo:

private int _myValue;

¡Buena suerte!

Answer 11

Usamos StyleCop para forzar la coherencia en todo nuestro código. StyleCop se usa dentro de Microsoft para imponer un conjunto común de mejores prácticas para el diseño, la legibilidad, el mantenimiento y la documentación del código fuente de C #.

Puede ejecutar StyleCop en tiempo de compilación y hacer que genere advertencias por violaciones de estilo.

Para responder a su pregunta específica, los campos privados deben estar en camelCase y deben tener el prefijo "this".

Answer 12

Estándar de codificación Philips Healtcare C #

MSDN - Eric Gunnerson

Editar: utilizo la palabra clave "this" para acceder a miembros no estáticos en C # y Java.

Answer 13

_camelCase for fields es común por lo que he visto (es lo que usamos en nuestro sitio y Microsoft lo prefiere para .NET Framework ).

Mi justificación personal para usar este estándar es que es más fácil escribir _ para identificar un campo privado que this.

Por ejemplo:

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

Versus

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

Encuentro que el primero es mucho más fácil de escribir y me impide asignar accidentalmente el parámetro llamado a lugar de this.a Esto se ve reforzado por una Regla de Mantenibilidad de Análisis de Código que establece:

• CA1500 Los nombres de las variables no deben coincidir con los nombres de los campos.

Mi otra razón, es que this. es opcional (el reafilado le pide que los elimine) si no colisiona con una variable local o nombre de parámetro, lo que hace que sea más difícil saber qué variable está utilizando. Si tiene un _ al comienzo de todos los campos privados, entonces siempre sabrá cuál es un campo y cuál tiene alcance local.

Answer 14

private string baseName; 
private string prefixName; 
private string suffixName; 

public GameItem(string _baseName, string _prefixName, string _suffixName) 
{ 
    this.baseName = _baseName; 
    this.prefixName = _prefixName; 
    this.suffixName = _suffixName; 
}