2009-05-09 37 views
5

¿Es una mala práctica que confiar en los valores por defecto implícitos, como:valores implícitos (por defecto) vs valores explícitos

class Node 
{ 
    int red; 
    int green; 
    int blue; 

    bool grayscale; 

    Node next; 
} 

En lugar de establecer explícitamente:

class Node 
{ 
    int red = 0; 
    int green = 0; 
    int blue = 0; 

    bool grayscale = false; 

    Node next = null; 
} 

Respuesta

3

no creo es una mala práctica ya que los valores predeterminados son algo que un desarrollador que trabaja en el lenguaje debería saber/estar obligado a aprender.

El único inconveniente que me viene a la mente es que el hecho de no enumerar los valores predeterminados puede hacer que las personas nunca miren el valor inicializado. Podría tomar un poco para darse cuenta en el caso en que se inicializa a algo diferente al predeterminado.

11

No, creo que está bien confiar en los valores predeterminados. Asignarlos explícitamente complicará el código. Además, tiene la ventaja de que es más fácil distinguir los campos a los que asigna valores no predeterminados.

+2

Estoy de acuerdo. Mientras menos información tenga en la pantalla para que mi cerebro la procese, mejor. – Vadim

7

Siempre los pondría, porque demuestra que has pensado cuáles deberían ser los valores iniciales de esos miembros.

bool isCool; 

podría significar "Sé que esto no es bueno en el arranque" o podría significar simplemente que no lo pensó.

bool isCool = false; 

es claramente una decisión deliberada.

2

Es sobre todo subjetiva, en mi humilde opinión.

Para mí, es demasiado "prolijo" a pesar de que es el valor predeterminado declarado explícitamente ... Todavía me ralentiza un poco al leer el código y seamos sinceros ... es redundante.

También creo que está en el código con más frecuencia de lo que debería porque las personas no conocen los valores predeterminados o tienen algún miedo irracional de que puedan cambiar el valor predeterminado de bool a verdadero en C# 5.0.

0

Prefiero dar los valores explícitamente. Hace menos esfuerzo en el cerebro intentado cargar los valores predeterminados de la memoria. Mejor tenerlos precausados. Ningún daño hecho.

como

string name = string.Empty; 

o

Guid userID = Guid.Empty; 
+1

Lo que sucede es que los valores predeterminados para cadena y Guid no son string.Empty y Guid.Empty, es nulo. Entonces, si quisieras que estuvieran "vacíos" para comenzar, tendrías que establecerlos explícitamente. –

+0

Para cadena estoy de acuerdo contigo, es nulo. Para Guid es actual Guid.Empty, si comprueba el valor de una variable "no inicializada". – User

+0

Es por eso que es mejor escribirlo explícitamente. Lo sabes de esta manera, los próximos chicos lo saben de manera diferente. ¿De qué sirve generar confusión? – User

1

Como alternativa a todas las respuestas antes, lo uso para poner esos valores iniciales en un constructor, por lo que no moleste en busca de initializacion de variable fuera debería ser.

class Node 
{ 
     int red; 
     int green; 
     int blue; 

     bool grayscale; 

     Node next; 
     public Node() { 
      red = 0; 
      green = 0; 
      blue = 0; 

      grayscale = false; 
      next = null; 
     } 
} 
1

Los desarrolladores son responsables de conocer cuáles son los valores predeterminados para los tipos de datos primitivos, por lo que no son estrictamente necesarios. Sin embargo, como algunos han indicado, demuestra que ha pensado en el problema.

Además, la gran mayoría de los tipos variables en su código serán tipos personalizados que haya creado. Los desarrolladores no son responsables de saber cuál es el valor predeterminado de su enumeración personalizada. Una buena comunicación requiere que especifique valores predeterminados en estos casos. Como somos criaturas de hábito, es mejor establecer el hábito de inicializar siempre sus variables. No importa si lo haces a nivel de clase o en tu constructor, siempre que seas coherente en tu enfoque.

Cuestiones relacionadas