Variables y constantes: nombrar los datos con los que trabajas
x1_final no es un nombre de variable: es una nota de auxilio que alguien ha decidido conservar dentro del programa. Puede funcionar, desde luego. También funcionaría llamar «cosa» a todos los parámetros de una familia, hasta el momento en que alguien necesitase saber cuál controla la anchura. Poner nombre a un dato parece un asunto elemental. Precisamente por eso resulta tan admirable el esfuerzo que dedicamos a hacerlo difícil después.
Una variable nos permite referirnos a un valor mediante un nombre durante la ejecución de un programa. Ese nombre participa en operaciones, se puede consultar y, cuando las reglas del lenguaje y la declaración lo permiten, puede recibir otro valor. Vamos a seguir dos datos de un espacio ficticio y una configuración de revisión en Python y C#. La cuestión que quiero resolver es pequeña: cuando cambias el nivel que quieres revisar, ¿has cambiado también el nivel del espacio? El programa no debería necesitar una reunión para aclararlo.
Nombrar el dato obliga a decidir qué representa
Supongamos que estamos preparando una revisión sobre un espacio cuyo nivel es L01. También hemos decidido que el alcance inicial de la revisión sea L01. Los dos valores coinciden, pero representan cosas diferentes: uno describe un dato recibido y el otro una elección de la operación. Confundirlos sería bastante fácil si los guardásemos en un único nombre como nivel y lo fuéramos reutilizando según lo que hiciera falta en cada línea.
En Python podemos escribir:
nivel_del_espacio = "L01"
nivel_objetivo = "L01"
Cada instrucción asocia el nombre de la izquierda con el valor de la derecha. Las comillas indican aquí un texto: L01 es una etiqueta de nivel en nuestro ejemplo, no un número con el que vayamos a calcular. La introducción oficial a Python presenta la asignación y el uso posterior de las variables. No hace falta memorizar todo el lenguaje para reconocer lo que conservan estas dos líneas.
Los nombres ayudan a mantener la diferencia aunque el contenido coincida. nivel_del_espacio habla del registro; nivel_objetivo, del filtro que utilizaremos. Más adelante podremos preguntar si ambos coinciden para decidir si revisar el espacio. Por ahora basta con separar las responsabilidades. Es un trabajo modesto y bastante menos heroico que depurar una aplicación cuyo nivel cambia de significado tres veces antes de llegar al informe.
En C# podemos expresar los mismos valores con declaraciones de texto:
string nivelDelEspacio = "L01";
string nivelObjetivo = "L01";
string declara el tipo de dato de esas variables y el punto y coma termina cada instrucción. Los nombres utilizan otra convención habitual: palabras enlazadas mediante mayúsculas interiores. La intención del ejemplo es la misma en los dos lenguajes, pero las reglas de declaración y tipos no son intercambiables. En la referencia de declaraciones de C# puedes situar esa diferencia sin deducirla a partir del aspecto visual de las líneas.
Reasignar una elección no modifica el dato del que partiste
La revisión cambia de alcance y ahora debe dirigirse a L02. Si queremos conservar el dato recibido del espacio, la instrucción que cambia es la del objetivo. El siguiente programa permite observar los dos valores antes y después:
nivel_del_espacio = "L01"
nivel_objetivo = "L01"
print(nivel_del_espacio)
print(nivel_objetivo)
nivel_objetivo = "L02"
print(nivel_del_espacio)
print(nivel_objetivo)
Guárdalo como variables.py y ejecútalo con el intérprete del ejercicio. Si has preparado el entorno en Windows como explicamos antes, el comando será .\.venv\Scripts\python.exe variables.py. Las cuatro líneas de salida deben ser L01, L01, L01 y L02, en ese orden. La tercera línea conserva el nivel del espacio; la cuarta muestra la nueva elección de revisión.
La asignación no era una fórmula que enlazase permanentemente ambos nombres. Cada variable de este ejemplo recibió el texto indicado y después reasignamos únicamente nivel_objetivo. Tampoco estamos escribiendo en un modelo BIM: cambiar este nombre dentro del programa no mueve un espacio de planta. Para modificar un dato de una aplicación externa necesitaríamos una operación específica y sus permisos. Una variable no trae una licencia de intervención sobre todo lo que su nombre recuerda.
La versión C# conserva el mismo recorrido:
string nivelDelEspacio = "L01";
string nivelObjetivo = "L01";
Console.WriteLine(nivelDelEspacio);
Console.WriteLine(nivelObjetivo);
nivelObjetivo = "L02";
Console.WriteLine(nivelDelEspacio);
Console.WriteLine(nivelObjetivo);
Si has instalado el SDK de .NET 8 y quieres ejecutar la comparación, crea un proyecto de consola en una carpeta de ejercicio:
dotnet new console --name Variables --framework net8.0
cd Variables
Sustituye el contenido de Program.cs por el bloque anterior y ejecuta dotnet run dentro de esa carpeta. Console.WriteLine muestra cada valor en una línea. El resultado esperado coincide con el de Python, lo que permite comparar el significado sin fingir que la sintaxis es idéntica. No necesitas instalar C# si has elegido seguir los ejercicios con Python: el segundo bloque es un contraste, no otra obligación antes de aprender el concepto.
Para estos textos sencillos el seguimiento resulta directo. Cuando empecemos a guardar colecciones y objetos aparecerán preguntas sobre referencias, mutabilidad y copias. No utilizaría esta demostración para afirmar que asignar siempre crea una copia independiente de cualquier dato. Esa promesa duraría exactamente hasta encontrar una lista compartida. Aquí estamos comprobando una reasignación de nombres que contienen etiquetas de texto.
Un nombre útil conserva el significado y la unidad
Podemos añadir una altura de 3,2 metros al espacio. En el código numérico de estos ejemplos se escribe con punto decimal:
altura_m = 3.2
En C# podríamos declararla así:
double alturaMetros = 3.2;
El nombre indica la magnitud y su unidad. Eso no añade por sí solo una comprobación de unidades al programa, pero permite reconocer qué pretende representar el valor. Si mañana recibimos 3200 milímetros, asignarlos a altura_m sin convertirlos haría que el nombre mintiera. El ordenador podría continuar calculando con total tranquilidad: los nombres no sustituyen las reglas que verifican la entrada.
También conviene evitar nombres que prometen una conclusión antes de haberla calculado. altura_correcta resulta engañoso si solo almacena una medición; altura_m conserva el dato sin adjudicarle una aprobación. Más adelante una condición podrá decidir si satisface un criterio de proyecto. Mantener separados dato, criterio y resultado facilita investigar una discrepancia sin preguntarse cuál de los tres estamos viendo.
No propondría escribir nombres interminables para demostrar responsabilidad. Si el contexto ya identifica el espacio, altura_m puede ser suficiente. Si se comparan dos espacios, habrá que distinguirlos. El criterio es que quien lee pueda relacionar el nombre con su función sin consultar al autor. Los acrónimos privados y los números de versión añadidos al nombre suelen hacer justo lo contrario, aunque proporcionen una agradable sensación de control a quien los inventó.
Otra decisión importante es no tratar el nombre visible de una variable como la identidad de un elemento BIM. Llamar a un dato puerta_1 puede servir en un ejercicio, pero no acredita que se refiera a la misma puerta entre archivos o ejecuciones. Para eso conservaremos identificadores dentro de los datos. Un nombre de código ayuda a entender el programa; un identificador ayuda a relacionarlo con el objeto que describe. La semejanza entre las palabras no las convierte en el mismo mecanismo.
Una constante expresa una decisión de estabilidad, con reglas distintas
Imagina que queremos acompañar los resultados con un código de ejercicio que se mantendrá durante toda la ejecución: REV-PUERTAS. En Python podemos utilizar una convención de mayúsculas:
CODIGO_DEL_EJERCICIO = "REV-PUERTAS"
Ese nombre avisa a quien lee de que no pretendemos reasignarlo. Python no impide una nueva asignación únicamente porque lo hayamos escrito en mayúsculas. Si después aparece una instrucción que cambia el valor, la convención por sí sola no la bloqueará. No vendería una advertencia para personas como si fuera una protección impuesta por el intérprete; bastante trabajo tiene ya la documentación sin tener que fingir capacidades de ejecución.
En C#, una constante local puede declararse mediante const:
const string CodigoDelEjercicio = "REV-PUERTAS";
En este caso la declaración tiene consecuencias del lenguaje: intentar reasignar esa constante es un error de compilación. La referencia oficial de const explica los valores que admite y sus condiciones. No debemos trasladar ese comportamiento a la convención de mayúsculas de Python solo porque las dos formas expresen nuestra intención de mantener un valor.
Eso tampoco significa que cualquier dato que hoy no cambie deba convertirse en una constante. El nivel objetivo pertenece a la configuración de la revisión: queremos poder cambiarlo entre operaciones. El nivel del espacio pertenece a la información de entrada. El código fijo del ejercicio, en cambio, puede tener sentido como constante en una implementación concreta. Lo que estamos decidiendo es qué papel tiene cada valor y quién puede variarlo, no una competición para inmovilizar el mayor número de líneas.
Una configuración de proyecto puede mantenerse estable mientras se ejecuta una comprobación y cambiar al preparar otra. En ese caso interesa conservar qué configuración se utilizó con cada resultado, no esconderla entre supuestas verdades universales del programa. Esta diferencia será especialmente útil cuando los catálogos y criterios de validación procedan de archivos o servicios externos.
Comprobar los cambios antes de utilizarlos como decisiones
El ejercicio puede revisarse sin una herramienta BIM. Primero anticipa las cuatro líneas de salida y después ejecuta el programa. Cambia solo nivel_objetivo y comprueba que nivel_del_espacio conserva L01. A continuación cambia el dato recibido y deja el objetivo intacto. Cada modificación debería permitirte explicar qué información ha cambiado y qué decisión sigue igual.
En C# puedes ensayar por separado una reasignación de CodigoDelEjercicio para observar el error de compilación; después retira esa instrucción y vuelve a compilar el ejemplo correcto. En Python la misma intención expresada en mayúsculas no bloqueará una reasignación. La diferencia es parte de lo que hay que aprender, no una molestia que debamos ocultar para que ambos ejemplos parezcan equivalentes.
Si quieres compartir una dificultad concreta en los comentarios, trae dos nombres y explica qué representan. «No sé si esta variable está bien» obliga a adivinar casi todo; «uso nivel para el dato del espacio y también para el filtro» ya permite discutir una decisión. A veces la mejora más útil de un programa no consiste en añadir una función. Consiste en dejar de llamar igual a dos cosas distintas y esperar que el siguiente humano lea nuestras intenciones.
Respuestas