C cuestión de estilo # programación - Asignación de null antes de la asignación real

Question

¿Hay una buena razón (ventaja) para la programación de este estilo

XmlDocument doc = null; 
doc = xmlDocuments[3]; 

vs

XmlDocument doc = xmlDocuments[3]; 

lo he visto muchas veces, pero me sólo parece demasiado prolijo

Answer 1

No, generalmente se considera la mejor práctica declarar una variable lo más tarde posible, preferiblemente configurándola en el punto de declaración. El único momento en que yo no hago eso es cuando tengo que fijar una variable condicional, o no lo establecido en un ámbito más restrictivo:

String name; 
using (TextReader reader = ...) 
{ 
    // I can't declare name here, because otherwise it isn't 
    // accessible afterwards 
    name = reader.ReadToEnd(); 
} 

razones de la declaración en el punto de inicio del consumo cuando sea posible:

• Mantiene el tipo de variable cerca de su uso, no es necesario desplazarse hacia atrás en el método para encontrarlo.
• Mantiene el alcance lo más estrecho posible, lo que hace que el uso de la variable sea más obvio.

Answer 2

me gustaría ir con

void Foo() 
{ 
    XmlDocument doc; 

    //Do other code here 

    //Create doc 
    doc = xmlDocuments[3]; 
} 

Como doc no se puede utilizar hasta más adelante en el método. Tiene más sentido crear un documento justo antes de ser utilizado. Más fácil de leer (menos desplazamiento).

Answer 3

me gustaría utilizar

XmlDocument doc = xmlDocuments[3]; 

declarar las variables que se utilizan.

Answer 4

Siempre trato de declarar y asignar variables en la misma fila si es posible, por lo que en este caso intentaré usar la segunda opción. Menos líneas de código, menos variables declaradas para tener en cuenta al leer el código también. Al final, creo que todo se trata de las reglas de codificación que usted y su equipo usan. Hemos tenido reglas de codificación que dicen declarar todas las variables locales al principio del método, así que he visto ambos estilos de programación.

Answer 5

Yo prefiero usar éste:

XmlDocument doc = null; 
//blah blah 
doc = xmlDocuments[3]; 

sólo quiero asignar y utilizar 'doc' cuando se requiere ..

Si quiero usarlo inmediatamente después de la asignación voy por

XmlDocument doc = xmlDocuments[3]; 

Answer 6

Si la variable 'doc' está asignada después de se declara que no, no veo ningún motivo por el que quiera hacer eso. En cualquier caso, ciertamente no es mi estilo.

Answer 7

Idealmente, la declaración y la asignación se deben emparejar para la legibilidad del código. De hecho, ReSharper recogerá cualquier excepción a esto y sugerirá que se unan.

Answer 8

Son estilos diferentes, y ninguno de ellos es objetivamente mejor que el otro. Es solo una cuestión de gusto.Usted puede declarar la variable primero y luego asignar un valor a la misma:

XmlDocument doc; 
doc = xmlDocuments[3]; 

O bien, puede hacer ambas cosas en el mismo comunicado:

XmlDocument doc = xmlDocuments[3]; 

Sin embargo, esta forma:

XmlDocument doc = null; 
doc = xmlDocuments[3]; 

Asignar una referencia nula a la variable y luego reemplazarla inmediatamente con una referencia diferente, es totalmente inútil.

Answer 9

Como han señalado los otros, el primer estilo puede ser útil si necesita declarar la variable fuera del alcance de un ciclo, si o algo más. Pero en la mayoría de los casos creo que este estilo es un remanente de los viejos tiempos de Visual Basic 6 (y anteriores) donde siempre había que declarar una variable antes de usar en.

Old VB no era compatible con su segundo estilo y por lo tanto el primer estilo sigue siendo popular ...

Answer 10

Me gusta pensar en las variables como "compartidas" o "no compartidas" en el sentido de que algunas variables se deben usar en varias ubicaciones de la clase o método, y algunas solo se necesitan para usar una vez Para el primero, los declaro a todos en la parte superior del bloque relevante, este último lo declaro justo antes de usarlo.

Todo depende de dónde necesite usarlos.

Caso 1:

Xyz xyz = new Xyz; // Declared at the top. 
// Loads of unrelated code in-between... 
xyz.abc(); 
// More unrelated code in-between... 
xyz.def(stuff); 

Caso 2:

// Loads of unrelated code above... 
Xyz xyz = new Xyz; // Declared in a 'block'. 
xyz.abc(); 
xyz.def(stuff); 
xyz.destroy(); 
// More unrelated code below... 

Answer 11

estoy de acuerdo en su mayoría con Jon (no hablar de que por lo general estoy de acuerdo con él :-).

que tienen opciones:

1.

//Do something... 
XmlDocument doc = xmlDocuments[3]; 
//use doc 
//Do something... 

2.

//Do something... 
XmlDocument doc = null; 
doc = xmlDocuments[3]; 
//Use doc 
//Do something... 

3.

//Do something... 
XmlDocument doc = null; 
//...Do something with other variables etc... 
doc = xmlDocuments[3]; 
//Do something... 
//Use doc 

4.

//Do something... 
XmlDocument doc = null; 
//...Do something with other variables etc... 
doc = xmlDocuments[3]; 
//Use doc 
//Do something... 

5.

//Do something... 
XmlDocument doc = null; 
doc = xmlDocuments[3]; 
//Do something... 
//Use doc 

6.

//Do something... 
XmlDocument doc = xmlDocuments[3]; 
//Do something... 
//use doc 

espero que se puede ver que la opción 1 tiene mucho sentido.

Lo mejor es mantener la declaración, la definición y la inicialización como "juntas" como sea posible. La opción 1 es un ejemplo de declaración, definición e inicialización hechas juntas en una línea.Se podría comprimir aún más:

var doc = xmlDocuments[3]; 

Vocabulario (independiente del idioma):

• Declaración: Coder introduce nuevo nombre para el compilador.
• Encuadernación de texto: escriba inferencia, use súper tipo, etc.
• Definición: Coder hace que el compilador reserve espacio. (en la pila, etc., tenga en cuenta que los nombres externos no necesitan espacio)
• Inicialización: el codificador asigna valor la primera vez durante la definición. El compilador realiza la inicialización (a valores nulos, 0, valores predeterminados, etc.) en la mayoría de los casos si el codificador omite la inicialización.
• Uso: Obvio!
• Alcance: ¡Obvio!
• Accesibilidad, cuando corresponda. : ¡Obvio!
• Modificador: nivel de Instancia, nivel de clase, nivel de método, constante, de sólo lectura, etc.

espero que esto ayude.