Inicializar campos de clase en constructor o en declaración?

En C# no importa. Las dos muestras de código que das son totalmente equivalentes. En el primer ejemplo el compilador de C# (o es el CLR?) construirá un constructor vacío e inicializará las variables como si estuvieran en el constructor. Si ya hay un constructor entonces cualquier inicialización "arriba" se moverá a la parte superior de la misma.

En términos de mejores prácticas, el primero es menos propenso a errores que el segundo, ya que alguien podría agregar fácilmente otro constructor y olvidarse de encadenar se.

La semántica de C# difiere ligeramente de Java aquí. En C# la asignación en la declaración se realiza antes de llamar al constructor de superclase. En Java se hace inmediatamente después de lo cual permite 'esto' para ser utilizado (particularmente útil para clases internas anónimas), y significa que la semántica de las dos formas realmente coinciden.

Si puede, haga que los campos sean definitivos.

Creo que hay una advertencia. Una vez cometí tal error: Dentro de una clase derivada, traté de "inicializar en la declaración" los campos heredados de una clase base abstracta. El resultado fue que existían dos conjuntos de campos, uno es "base" y otro son los recientemente declarados, y me costó bastante tiempo depurar.

La lección: para inicializar campos heredados, lo haría dentro del constructor.

Asumiendo el tipo en su ejemplo, definitivamente prefiere inicializar los campos en el constructor. Los casos excepcionales son:

• Campos en clases/métodos estáticos
• Campos escritos como static/final/et al

Siempre pienso en el campo que aparece en la parte superior de una clase como la tabla de contenido (lo que se contiene aquí, no cómo se usa), y el constructor como la introducción. Los métodos, por supuesto, son capítulos.

¿Y si te lo digo, depende?

En general inicializo todo y lo hago de manera consistente. Sí, es demasiado explícito, pero también es un poco más fácil de mantener.

Si estamos preocupados por el rendimiento, bueno, entonces inicializo solo lo que hay que hacer y lo coloco en las áreas que da más por el dinero.

En un sistema en tiempo real, me pregunto si incluso necesito la variable o constante en absoluto.

Y en C++ a menudo hago junto a ninguna inicialización en colocarlo y moverlo a una función Init (). ¿Por qué? Bueno, en C++ si inicializas algo que puede generar una excepción durante la construcción de objetos, te abres a fugas de memoria.

En Java, un inicializador con la declaración significa que el campo siempre se inicializa de la misma manera, independientemente del constructor que se use (si tiene más de uno) o los parámetros de sus constructores (si tienen argumentos), aunque un constructor puede cambiar posteriormente el valor (si no es final). Por lo tanto, el uso de un inicializador con una declaración sugiere al lector que el valor inicializado es el valor que tiene el campo en todos los casos, independientemente del constructor se utiliza e independientemente de los parámetros pasados a cualquier constructor. Por lo tanto, use un inicializador con la declaración solo si, y siempre si, el valor para todos los objetos construidos es el mismo.

Hay muchas y diversas situaciones.

Solo necesito una lista vacía

La situación es clara. Solo necesito preparar mi lista y evitar que se lance una excepción cuando alguien agrega un elemento a la lista.

public class CsvFile
{
    private List<CsvRow> lines = new List<CsvRow>();

    public CsvFile()
    {
    }
}

Conozco los valores

Sé exactamente qué valores quiero tener por defecto o necesito usar alguna otra lógica.

public class AdminTeam
{
    private List<string> usernames;

    public AdminTeam()
    {
         usernames = new List<string>() {"usernameA", "usernameB"};
    }
}

O

public class AdminTeam
{
    private List<string> usernames;

    public AdminTeam()
    {
         usernames = GetDefaultUsers(2);
    }
}

Lista vacía con posibles valores

A veces espero una lista vacía por defecto con la posibilidad de agregar valores a través de otro constructor.

public class AdminTeam
{
    private List<string> usernames = new List<string>();

    public AdminTeam()
    {
    }

    public AdminTeam(List<string> admins)
    {
         admins.ForEach(x => usernames.Add(x));
    }
}

Establecer el valor en la declaración supone un ligero beneficio para el rendimiento. Si lo configura en el constructor, en realidad se está configurando dos veces (primero al valor predeterminado, luego se restablece en el ctor).

El diseño de C# sugiere que se prefiere la inicialización en línea, o no estaría en el lenguaje. Siempre que pueda evitar una referencia cruzada entre diferentes lugares en el código, generalmente estará mejor.

También existe la cuestión de la consistencia con la inicialización de campos estáticos, que necesita estar en línea para un mejor rendimiento. Las Directrices de Diseño del Marco para El Diseño del Constructor dicen esto:

✓ CONSIDERE inicializar los campos estáticos en línea en lugar que el uso explícito de constructores estáticos, porque el tiempo de ejecución es capaz de optimizar el rendimiento de los tipos que no tienen un constructor estático definido explícitamente.

"Considerar" en este contexto significa hacerlo a menos que haya una buena razón para no hacerlo. En el caso de los campos del inicializador estático, una buena razón sería si la inicialización es demasiado compleja para ser codificada en línea.

Ser consistente es importante, pero esta es la pregunta que debes hacerte: "¿Tengo un constructor para algo más?"

Normalmente, estoy creando modelos para transferencias de datos que la clase en sí no hace nada excepto trabajar como alojamiento para variables.

En estos escenarios, normalmente no tengo ningún método o constructor. Sería una tontería para mí crear un constructor con el exclusivo propósito de inicializar mis listas, especialmente porque puedo inicializarlas en línea con el declaración.

Así que como muchos otros han dicho, depende de su uso. Mantenlo simple, y no hagas nada extra que no tengas que hacer.

Considere la situación en la que tiene más de un constructor. ¿La inicialización será diferente para los diferentes constructores? Si serán los mismos, entonces ¿por qué repetir para cada constructor? Esto está en línea con la declaración kokos, pero puede no estar relacionado con los parámetros. Digamos, por ejemplo, que desea mantener una bandera que muestre cómo se creó el objeto. Entonces ese indicador se inicializaría de manera diferente para diferentes constructores independientemente de los parámetros del constructor. Por el otro a mano, si repite la misma inicialización para cada constructor, deja la posibilidad de que (involuntariamente) cambie el parámetro de inicialización en algunos de los constructores pero no en otros. Por lo tanto, el concepto básico aquí es que el código común debe tener una ubicación común y no ser potencialmente repetido en diferentes ubicaciones. Por lo tanto, yo diría que siempre lo incluyas en la declaración hasta que tengas una situación específica en la que ya no funcione para ti.

Normalmente intento que el constructor no haga nada más que obtener las dependencias e inicializar los miembros de instancia relacionados con ellas. Esto te hará la vida más fácil si quieres probar unitariamente tus clases.

Si el valor que va a asignar a una variable de instancia no se ve influenciado por ninguno de los parámetros que va a pasar a su constructor, asígnelo en el momento de la declaración.

No es una respuesta directa a su pregunta sobre la mejor práctica pero un punto de actualización importante y relacionado es que en el caso de una definición de clase genérica, o bien dejar que el compilador inicialice con valores predeterminados o tenemos que usar un método especial para inicializar los campos a sus valores predeterminados (si eso es absolutamente necesario para la legibilidad del código).

class MyGeneric<T>
{
    T data;
    //T data = ""; // <-- ERROR
    //T data = 0; // <-- ERROR
    //T data = null; // <-- ERROR        

    public MyGeneric()
    {
        // All of the above errors would be errors here in constructor as well
    }
}

Y el método especial para inicializar un campo genérico a su valor predeterminado es el siguiente:

class MyGeneric<T>
{
    T data = default(T);

    public MyGeneric()
    {           
        // The same method can be used here in constructor
    }
}