Evitar conflictos de nombres
Un conflicto de nombres Se produce al tratar de crear o utilizar un identificador que ya estaba definido. En algunos casos, los conflictos de nombres generan errores del tipo "Detectado nombre ambiguo " o "Declaración duplicada en el alcance ". Los conflictos de nombres que no se detectan pueden producir fallos de programación en el código y generar resultados erróneos, especialmente, si no se declaran explícitamente todas las variables antes de utilizarlas por primera vez.
La mayor parte de los conflictos de nombres se pueden evitar comprendiendo las características de alcance de los identificadores de datos, objetos y procedimientos. Visual Basic tiene tres niveles de alcance: nivel de procedimiento, nivel de módulo privado y nivel de módulo público.
El conflicto de nombres se puede producir cuando un identificador:
- Es visible en más de un nivel de alcance.
- Tiene dos significados distintos en el mismo nivel.
Por ejemplo, los procedimientos pertenecientes a módulos distintos pueden compartir el mismo nombre. Es posible, por tanto, definir un procedimiento llamado MiSub en los módulos Mod1 y Mod2. No se producirá ningún conflicto si cada uno de estos procedimientos es llamado únicamente por otros procedimientos de su mismo módulo. Sin embargo, puede producirse un error si hay una llamada a MiSub desde un tercer módulo y no se ha proporcionado ninguna identificación adicional que permita distinguir entre los dos MiSub existentes.
La mayor parte de los conflictos de nombres se pueden evitar asignando a cada identificador un prefijo que consista en el nombre del módulo y, si es necesario, un nombre proyecto. Por ejemplo:
MiProyecto.MiMódulo.MiSub MiProyecto.MiMódulo.MiVariable
El código anterior efectúa una llamada al procedimiento Sub MiSub y pasa como argumento la variable MiVariable. Se puede utilizar cualquier combinación de calificadores para diferenciar identificadores inicialmente idénticos.
Visual Basic hace corresponder cada referencia a un identificador a la declaración de identificador "más parecida" que encuentra. Por ejemplo, si MiId se declara como Public en dos módulos de un proyecto (Mod1 y Mod2), será posible especificar sin ninguna calificación el identificador MiId declarado en Mod2 desde el mismo módulo Mod2, pero deberá calificarse como Mod2.MyId para especificarlo en Mod1. Lo mismo es también cierto en el caso de que Mod2 esté en un proyecto al que se hace referencia directamente, aunque sea distinto. Sin embargo, si Mod2 está en un proyecto al que se hace referencia indirectamente, es decir, en un proyecto al que se hace referencia en el proyecto directamente de referencia, las referencias a la variable MiId del módulo Mod2 deben ir siempre precedidas por el nombre del proyecto como calificador. Si se hace una referencia a MiId desde un tercer módulo, al que se hace referencia directamente, la relación se establecerá con la primera declaración que se localice durante la búsqueda:
- Proyectos a los que se hace referencia directamente, en el orden en que aparecen en el cuadro de diálogo Referencias del menú Herramientas.
- Los módulos de cada proyecto. Observe que no hay ningún orden inherente a los módulos de un proyecto.
No se pueden utilizar nuevamente nombres de objetos de la aplicación host, por ejemplo R1C1 en Microsoft Excel, a distintos niveles de alcance.
Sugerencia Nombres ambiguos, declaraciones duplicadas, identificadores no declarados y procedimientos no localizables son algunos de los errores más comunes causados por conflictos de nombres. Es posible evitar algunos posibles conflictos de nombres y los errores de programación asociados, iniciando cada módulo con una instrucción Option Explicit que obliga a declarar explícitamente las variables antes de que puedan ser utilizadas.