Saltar al contenido

Conocer el alcance de las variables locales

Las reglas generales para la C# son:

  • Es erróneo que una declaración de variables locales y un espacio de declaración de variables locales anidado contengan elementos del mismo nombre.
  • Se producirá un error de tiempo de compilación si, dentro del ámbito de una variable local, se encuentra en una posición textual que se produce antes del declarante de la variable local. Si la declaración de la variable local está implícita, seguirá habiendo un error para referirse a esa variable en su local-variable-declarador.

Estas reglas pueden ser entendidas y recordadas con un simple ejemplo.

Conocer el alcance de las variables locales
Conocer el alcance de las variables locales
1234567891011121314151617classClarity{publicint time;voidFunction(){int seconds; seconds =0;// (Línea 1) Se vinculará a la variable local definida arriba time =0;// (Línea 2) Se vincula al tiempo de campo{ seconds ="s";// (Línea 3) Se vinculará a la variable local definida abajostring seconds; time ="s";// (Línea 4) Se vincula a la variable local definida abajo.string time;}}}

csharp

En la línea 2, uno pensaría que los segundos se unirían a Claridad.segundos como en la línea 1. Sin embargo, la especificación de C# define claramente que el nombre se resolverá al alcance más cercano. En las líneas 3 y 4 habrá errores de compilación.

Sin embargo, se permite una referencia a la variable local dentro de el declarante, aunque no está tipificada implícitamente. Así que lo siguiente será cierto:

12int a =(x =5);// Allowedvar b =(y =10);// Resultará en un error

csharp

En la primera declaración, ya hemos declarado que el tipo es «int». Cuando se produce la unión, está bien porque el lado izquierdo (inicializador variable) es apto. Mientras tanto, no teníamos un tipo para b inicialmente, así que cuando la unión tiene lugar, no estamos seguros de si 10 puede ser asignado a b o no.

Una cosa que se puede hacer es ocultar el nombre . Esto sólo se permite en los campos que no están referenciados en el ámbito actual. Se nos permite redefinir una variable como una cadena porque no ha sido referenciada aún en el ámbito de un método determinado.

Nos damos cuenta de que este método de utilizar un nombre antes de su declarante hace que el compilador genere errores, lo cual no es lo ideal. En términos sencillos, el nombre simple se resuelve a cualquier declaración que se declare dentro de su bloque actual, independientemente de que exista una variable con el mismo nombre o una definición fuera del bloque.

Además, en el Compilador C# de 2005, vinculamos incorrectamente ambas declaraciones de s a la variable local externa, y la línea 1 se uniría perfectamente. Pero hubo un error en la línea 2 informando que la cadena no es convertible a int. También hubo un error en la línea 3 que indica que no se puede redeclarar s a otra cosa.

Luego, en el Compilador C# de 2008, esto se arregló para reflejar correctamente la especificación. Tanto la línea 1 como la línea 2 se unirían a la línea 3. Dado que estaban textualmente antes de su declaración, ambas darían un error, diciendo que estaban siendo usadas antes de ser declaradas. La línea 3 también da un error de que no se puede redeclarar s.