language agnostic - ¿Debería siempre/nunca/nunca inicializar campos objeto a valores predeterminados?
language-agnostic coding-style (17)
Creo que debería hacerse si realmente ayuda a que el código sea más comprensible.
Pero creo que este es un problema general con todas las características del lenguaje. Mi opinión sobre eso es: si es una característica oficial del idioma, puede usarlo. (Por supuesto, hay algunas características anti que deberían usarse con precaución o evitarse en absoluto, como una option explicit faltante option explicit en Visual Basic o herencia de diamantes en C ++)
Hubo un tiempo en el que estaba muy paranoica y añadí todo tipo de inicializaciones innecesarias, conversiones explícitas, bloqueos über-paranoid try-finally ... Una vez incluso pensé en ignorar el auto-boxing y reemplazar todas las ocurrencias con conversiones de tipo explícitas, solo "para estar seguros".
El problema es: no hay fin. Puede evitar casi todas las funciones de idioma, porque no quiere confiar en ellas.
Recuerda: es solo magia hasta que lo entiendas :)
Código de diseño de la pregunta aquí.
Miré this pregunta que pregunta si .NET CLR siempre inicializará los valores de campo. (La respuesta es sí .) Pero me sorprende que no estoy seguro de que siempre sea una buena idea hacer que haga esto. Mi pensamiento es que si veo una declaración como esta:
int myBlorgleCount = 0;
Tengo una idea bastante buena de que el programador espera que el conteo comience en cero, y está de acuerdo con eso, al menos para el futuro inmediato. Por otro lado, si acabo de ver:
int myBlorgleCount;
No tengo una idea real inmediata si 0 es un valor legal o razonable. Y si el programador acaba de comenzar a leer y modificarlo, no sé si el programador quiso comenzar a usarlo antes de establecer un valor para él, o si esperaban que fuera cero, etc.
Por otro lado, algunas personas bastante inteligentes y la utilidad de limpieza de código de Visual Studio me dicen que elimine estas declaraciones redundantes. ¿Cuál es el consenso general sobre esto? (¿Hay consenso?)
Marqué esto como agnóstico del lenguaje, pero si hay un caso extraño en el que es específicamente una buena idea ir contra la corriente para un idioma en particular, eso probablemente valga la pena señalar.
EDITAR : Si bien dije que esta pregunta era independiente del lenguaje, obviamente no se aplica a lenguajes como C, donde no se realiza ninguna inicialización de valor.
EDITAR : Aprecio la respuesta de John, pero es exactamente lo que no estoy buscando. Entiendo que .NET (o Java o lo que sea) hará el trabajo e inicializará los valores de manera consistente y correcta. Lo que estoy diciendo es que si veo un código que modifica un valor que no ha sido explícitamente establecido previamente en el código, yo, como mantenedor de código, no sé si el codificador original significaba que era el valor predeterminado, o simplemente se olvidó de establecer el valor, o esperaba que se establezca en otro lugar, etc.
Creo que mucho de eso se reduce a experiencias pasadas.
En idiomas más antiguos y sin control, la expectativa es que el valor sea desconocido. Esta expectativa es retenida por programadores provenientes de estos idiomas.
Casi todos los lenguajes modernos o administrados tienen valores definidos para las variables creadas recientemente, ya sea de constructores de clase o características de lenguaje.
Por ahora, creo que está perfectamente bien inicializar un valor; lo que una vez estuvo implícito se vuelve explícito. A largo plazo, por ejemplo, en los próximos 10 a 20 años, las personas pueden comenzar a aprender que un valor predeterminado es posible, esperado y conocido, especialmente si se mantienen consistentes en todos los idiomas (por ejemplo, cadena vacía para cadenas, 0 para números) .
Creo que tiene sentido inicializar los valores si aclara la intención del desarrollador.
En C #, no hay sobrecarga, ya que todos los valores se inicializan de todos modos. En C / C ++, los valores no inicializados contendrán basura / valores desconocidos (lo que sea que haya en la ubicación de la memoria), por lo que la inicialización fue más importante.
Debería hacerlo, no es necesario, pero es mejor si lo hace, porque nunca se sabe si el idioma que está utilizando inicializa los valores. Al hacerlo usted mismo, se asegura de que sus valores estén inicializados y con valores predefinidos estándar establecidos. No hay nada de malo en hacerlo, excepto tal vez un poco de "tiempo perdido". Lo recomendaría fuertemente Si bien el elogio de John es bastante informativo, en el uso general, es mejor ir por el camino seguro.
En el caso donde no puedo establecerlo de inmediato a algo útil
int myValue = SomeMethod();
Lo estableceré en 0. Eso es más para evitar tener que pensar en lo que sería el valor de otra manera. Para mí, el hecho de que los enteros estén siempre configurados en 0 no está en la punta de mis dedos, así que cuando veo
int myValue;
me llevará un segundo sacar ese hecho y recordar lo que se establecerá, interrumpiendo mi proceso de pensamiento. Para alguien que tenga ese conocimiento fácilmente disponible, se encontrará con
int myValue = 0;
y me pregunto por qué diablos está esa persona poniéndolo en cero, cuando el compilador simplemente lo haría por ellos. Este pensamiento interrumpiría su proceso de pensamiento.
Entonces, haz lo que tenga más sentido tanto para ti como para el equipo en el que estás trabajando. Si la práctica común es establecerlo, configúralo; de lo contrario, no lo hagas.
En mi experiencia, he descubierto que la inicialización explícita de variables locales (en .NET) agrega más desorden que claridad.
Las variables de nivel de clase, por otro lado, siempre deben inicializarse. En el pasado definimos valores "nulos" personalizados para todo el sistema para tipos de variables comunes. De esta forma, siempre podríamos saber lo que no se inicializó por error y lo que se inicializó a propósito.
Esto está etiquetado como independiente del lenguaje, pero la mayoría de las respuestas se refieren a C #.
En C y C ++, la mejor práctica es inicializar siempre tus valores. Hay algunos casos en que esto se hará para usted, como variables globales estáticas, pero no debería haber un golpe de rendimiento de ningún tipo para inicializar de forma redundante estos valores con la mayoría de los compiladores.
Estoy de acuerdo contigo; puede ser detallado, pero me gusta ver:
int myBlorgleCount = 0;
Ahora, siempre escribo cadenas de caracteres iniciales:
string myString = string.Empty;
(Odio cadenas nulas)
Normalmente lo hago por cadenas y, en algunos casos, colecciones en las que no quiero nulos flotando. El consenso general donde trabajo es "No hacerlo explícitamente para tipos de valores".
Otra cosa que debes recordar es que si vas a usar propiedades automáticas, debes confiar en valores implícitos, como:
public int Count { get; set; }
Piense en el mantenimiento a largo plazo.
- Mantenga el código tan explícito como sea posible.
- No confíe en formas específicas de idioma para inicializarse si no es necesario. ¿Tal vez una versión más nueva del lenguaje funcionará de manera diferente?
- Los futuros programadores se lo agradecerán.
- La gerencia te lo agradecerá
- ¿Por qué ofuscar las cosas siquiera lo más mínimo?
Actualización: futuros mantenedores pueden venir de un fondo diferente. Realmente no se trata de lo que es "correcto" sino de lo que será más fácil a largo plazo.
Si un campo a menudo tendrá nuevos valores almacenados en él sin tener en cuenta lo que estaba allí anteriormente, y si debe comportarse como si un cero estuviera almacenado allí inicialmente pero no hay nada "especial" sobre cero, entonces el valor debe almacenarse explícitamente.
Si el campo representa un recuento o total que nunca tendrá un valor distinto de cero escrito en él directamente, sino que siempre tendrá otras cantidades agregadas o restadas, entonces cero debe considerarse un valor "vacío", y por lo tanto no necesita ser explícitamente fijado.
Para usar una analogía cruda, considere las siguientes dos condiciones:
- `if (xposition! = 0) ...
- `if ((flags & WoozleModes.deluxe)! = 0) ...
En el primer escenario, la comparación con el cero literal tiene sentido porque está buscando una posición que semánticamente no es diferente de ninguna otra. En el segundo escenario, sin embargo, sugeriría que la comparación con el cero literal no agrega nada a la legibilidad porque el código no está realmente interesado en si el valor de la expresión (flags & WoozleModes.deluxe) pasa a ser un número distinto de cero , sino más bien si es "no vacío".
No conozco ningún lenguaje de programación que proporcione formas separadas de distinguir valores numéricos para "cero" y "vacío", salvo que no se requiera el uso de ceros literales cuando se indique vacío.
Siempre está seguro al asumir que la plataforma funciona del mismo modo que la plataforma. La plataforma .NET inicializa todos los campos a los valores predeterminados. Si ve un campo que no está inicializado por el código, significa que el campo está inicializado por el CLR, no es que no esté inicializado.
Esta preocupación es válida para las plataformas que no garantizan la inicialización, pero no aquí. En .NET, más a menudo indica ignorancia del desarrollador, pensando que la inicialización es necesaria.
Otra resaca innecesaria del pasado es la siguiente:
string foo = null;
foo = MethodCall();
Lo he visto de personas que deberían saberlo mejor.
Siempre inicializo campos explícitamente en el constructor. Para mí, es EL lugar para hacerlo.
Yo no lo haría C # inicializa un int a cero de todos modos, por lo que las dos líneas son funcionalmente equivalentes. Uno es más largo y redundante, aunque es más descriptivo para un programador que no conoce C #.
Yo no los inicializaría. Si mantiene la declaración lo más cerca posible del primer uso, entonces no debe haber confusión.