¿Qué hicieron los programadores antes del alcance variable, donde todo es global?

40

Por lo tanto, estoy teniendo que lidiar con un lenguaje aparentemente arcaico (llamado PowerOn) donde tengo un método principal, algunos tipos de datos con los cuales definir variables y tengo la capacidad de tener sub-procedimientos (métodos esencialmente vacíos) que no Devuelve un tipo ni acepta ningún argumento. El problema aquí es que TODO es global. He leído sobre este tipo de idiomas, pero la mayoría de los libros tienen el enfoque "Ok, solemos usar un caballo y un carruaje, pero ahora, Aquí hay un auto, así que aprendamos a trabajar en ESO! " NUNCA reviviremos esos días ". Tengo que admitir que la mente está luchando para pensar fuera del alcance y la extensión .

Bueno, aquí estoy. Estoy tratando de averiguar cómo administrar mejor nada más que variables globales a través de varios métodos abiertos . Sí, incluso los iteradores para for loops deben definirse globalmente, lo cual me parece que estoy reciclando en diferentes partes de mi código.

Mi pregunta: para aquellos que tienen este tipo de experiencia, ¿cómo manejaron los programadores una gran cantidad de variables en un campo de juego global? Sentí que se convirtió en un truco de malabarismo mental, pero Estaría interesado en saber si hubo algún acercamiento conocido.

    
pregunta Chad Harrison 23.10.2012 - 18:20

9 respuestas

44

Necesitarás algún tipo de trucos de contabilidad mental (convenciones de nomenclatura, etc.) para mantenerlo en orden. También, documento, documento, documento. Dado que todas las variables son globales, tenga un solo documento con todas ellas en la lista, si puede.

Intente tener un pequeño número de variables que siempre use para temporarios, y recuerde que SON TEMPORALES. Al reutilizar constantemente los mismos, tendrás la costumbre de mantener un registro de dónde son válidos o no.

Además, desea consultar la documentación y asegurarse de saber qué tan largos pueden ser los nombres de las variables y cuántos caracteres son realmente únicos. No se NADA sobre PowerOn, pero si es lo suficientemente arcaico como para tener solo un alcance global, entonces es posible que tenga una longitud unitaria limitada en los identificadores.

He visto cosas antes con identificadores largos, pero cuyos identificadores solo fueron únicos en los primeros 8 caracteres. Así que podrías tener a RonnyRayGun y RonnyRayBlaster y en realidad son la misma variable. En tales casos, recomiendo mantener los nombres de las variables bajo el límite "único" para que sea menos probable que choquen accidentalmente.

    
respondido por el Michael Kohne 23.10.2012 - 18:31
53

Diccionario de datos.

En un repositorio central (generalmente la oficina del programador principal), había una carpeta de hojas sueltas, que contenía una página para cada variable global. La página dio el nombre, su definición, su propósito y las rutinas que lo configuraron o usaron.

Los primeros sistemas embebidos con RAM microscópica tenían un problema similar y una solución similar. El programador principal mantuvo el mapa maestro de RAM, hasta los bytes individuales, mostrando qué RAM fue utilizada por qué módulos para qué propósitos. Los programadores que necesitaban una asignación de RAM dedicada acudieron al programador principal, quien, después de discutir el asunto, hizo la entrada apropiada en el cuaderno y le dio a la persona su RAM. (No quiso estar en la piel del programador que tomó un byte de RAM sin borrarlo con el programador principal. Confíe en mí en esto).

Este problema también apareció cuando los programadores tuvieron que construir grandes sistemas en las primeras versiones de BASIC. Apareció para mí personalmente mientras utilizaba un administrador de "base de datos" muy primitivo llamado Info (producto de Henco, Inc. de Nueva Jersey, ¡HOPEFULAMENTE ahora!). Ambos idiomas tenían un vocabulario de nombre variable muy limitado.

    
respondido por el John R. Strohm 23.10.2012 - 18:45
8

El auge de los lenguajes de programación con alcance de bloque coincidió con la llegada de máquinas más rápidas y grandes, y eso no es una coincidencia. Las primeras computadoras tenían RAM medida en MB, kB o incluso en bytes; simplemente no hubo oportunidad de que incluso tuviera tantas variables que se confundirían cuando el programa creciera, porque los programas nunca fueron tan grandes . Los avances en los lenguajes de programación generalmente se hacían cuando las personas reconocían que sus viejos hábitos de programación no aumentaban cuando la arena se hacía más grande; El alcance del bloque se inventó como un mecanismo de defensa para los programadores contra su propia memoria limitada.

La computación también fue una actividad mucho más rara y exótica cuando los cómputos eran fantásticamente caros, y bien podría ser que solo los individuos ingenuos e inclinados particularmente matemáticamente se convirtieran en programadores en primer lugar (aunque tales comparaciones no son prácticas de probar, y ciertamente políticamente incendiario). En los primeros días, el software generalmente se enviaba gratis con una computadora para convencer a la gente a comprarlo en primer lugar; la idea de que los usuarios institucionales incluso intentarían escribir sus propios programas era desconocida al principio.

    
respondido por el Kilian Foth 23.10.2012 - 18:31
4

Dios mío, eso es hace muchos años (recuerdos burbujeantes :)).

No sé el idioma al que te refieres, pero en general nos adaptamos a lo que teníamos. No fue realmente un gran problema. Necesitaba prestar más atención a los nombres var que a menudo contenían (en forma abreviada, en esos días la cantidad de bytes era muy valiosa) referencia a sub o function, como mIORead1 si tenía un controlador para leer datos de un archivo 1, o tenías varias contravars como i, j, k, etc. que, según tu propio sistema, sabías para qué eran, si podían reutilizarse, etc. Era más duro (no había cascos ni guantes en ese entonces) :-)

    
respondido por el epistemex 23.10.2012 - 18:30
3

Esto es bastante similar a la programación de PLC, aunque los PLC modernos ahora le permiten tener "etiquetas" (también conocidas como variables) que son locales para un programa. Sin embargo, mucha gente simplemente programa usando todas las etiquetas globales.

Descubrí que, si vas a hacer eso, necesitas usar una convención de nomenclatura estructurada. Por ejemplo: Motor1_DriveContactor_Run . Si su idioma admite estructuras (a veces conocidas como tipos definidos por el usuario), también puede usarlas para crear una jerarquía de datos estructurada, como: Motor[1].DriveContactor.Run .

Eso mantiene todo organizado y, por lo general, la inteligencia es lo suficientemente decente como para ayudarte.

    
respondido por el Scott Whitlock 23.10.2012 - 18:42
2

En realidad aprendí a programar en un lenguaje llamado Authorware, donde todo era global. Por suerte, tenía Arrays y, después de cierto punto, algo llamado Listas, que eran similares a los objetos genéricos.

Un programa Authorware en realidad tenía una estructura física (Authorware se basaba en una metáfora del diagrama de flujo), y su lenguaje de scripting se basaba en el estilo antiguo de Pascal. Lo que hicimos fue relacionar la estructura física con los índices en una matriz, y con frecuencia los índices de matriz contendrían listas que trataríamos como un objeto local para la pieza física que estábamos usando.

Authorware fue diseñado para eLearning, por lo que uno de los íconos que teníamos era una página. Las páginas se adjuntarán a un marco. Por lo tanto, para la página 1, buscaríamos en un Array el índice 1 (Authorware fue 1 indexado) y extraeríamos los datos de esa página, que se almacenaría en una Lista que actuaría como un pseudoobjeto. La página tendría entonces una lógica que sacaría las "propiedades" del objeto por su nombre. Si no tiene nada como Objetos, pero tiene Arrays, simplemente puede tener una convención de qué datos van a dónde.

En realidad, no es tan diferente de lo que hacemos cuando recuperamos datos de una base de datos y realizamos una inyección de dependencia, excepto que todo es realmente global, y simplemente está eligiendo poner todo en pequeñas cajas y solo mirar las (s) ) estás preocupado en este momento.

Dependiendo de lo que estés tratando de hacer y de lo que admita tu idioma, esto podría ayudarte a al menos dividir las cosas en partes más manejables.

    
respondido por el Amy Blankenship 24.10.2012 - 02:11
1

Cuando estaba en la universidad nos enseñaron largamente sobre "El problema de la variable global", una colección de errores y problemas de mantenimiento de código causados por muchas variables globales.

Algunas variables son más peligrosas que otras.

Seguro : variables que no afectan el flujo de control, por ejemplo. Apellido

Peligroso : cualquier variable que afecte el flujo de control del programa, por ejemplo. Estado de entrega

Lo más peligroso primero:

  • Estado compuesto (modo y modo secundario)
  • Valores compuestos (total, subtotal)
  • Estado único (modo)
  • Valores únicos (conteo)

Para evitar el "problema de la variable global", debes

  • Documente cada variable y funcione.
  • Mantenga las variables relacionadas juntas (con el código que las usa) en la misma sección del código fuente.
  • Oculte las variables "peligrosas" para que otros programadores no sepan de su existencia. Evite usarlos directamente, especialmente en otras secciones del código.
  • Proporcione funciones que leen / escriben variables peligrosas (para que otros programadores no lo necesiten).

Para estructurar su código , cuando no haya ninguna estructura disponible en el idioma, utilice los comentarios y las convenciones de denominación:

/* --------------------------- Program mode ------------------------ */

var Mode_Standard = 1;      // Normal operation (SubMode unused)
var Mode_Backup   = 2;      // Backup mode      (SubMode is backup device)

var BackupMode_Disk = 1;    // SubMode: Backup to disk
var BackupMode_Tape = 2;    // SubMode: Backup to tape

var MainMode = Mode_Standard;
var SubMode = 0;

function Mode_SetBackup(backupMode)
{
    MainMode = Mode_Backup;
    SubMode = backupMode;
}

function Mode_SetStandardMode()
{
    MainMode = Mode_Standard;
    SubMode  = 0;
}

function Mode_GetBackupMode()
{
    if (MainMode != Mode_Backup)
        return 0;

    return SubMode;
}

/* --------------------------- Stock Control ------------------------ */

var Stock_Total =  123;      // Total stock       (including RingFenced)
var Stock_RingFenced = 22;   // Ring-fenced stock (always less than total)

// Adds further ring-fenced stock 
function Stock_AddRingFenced(quantity)
{
    Stock_Total      += quantity;
    Stock_RingFenced += quantity;
}

/* ------------------------- Customers ----------------------- */

var Customer_FirstName = "Tony";
var Customer_LastName  = "Stark";
    
respondido por el user147272 14.06.2016 - 16:19
0

No sé cómo lo hicieron.

Pero creo que los lenguajes OOP modernos tenían un problema muy similar con respecto a la colisión de nombres .

La solución está adoptando espacio de nombres . Es un concepto abstracto, pero ampliamente adoptado por varias implementaciones (paquetes Java, espacio de nombres .NET, módulos Python).

Si el idioma que está utilizando no tiene una limitación demasiado estrecha sobre la longitud de la denominación, puede aplicar el espacio de nombres a una buena denominación de variables.

Por lo tanto, el nombre de la variable también representa el ámbito de la variable.

Intenta definir un patrón de denominación como este: order_detail_product_code , order_detail_product_unit_price . O para los contadores o swaps temporales: tmp_i , tmp_swap .

    
respondido por el Alberto De Caro 24.10.2012 - 11:31
0

En los idiomas en los que todas las variables son globales (he usado un par), utilizamos una convención de nomenclatura de variables. Por ejemplo: si realmente quisiera usar una variable como global, podría usar el prefijo "m_" o "_". Por supuesto, esto aún depende de los desarrolladores para tener esta disciplina

    
respondido por el bytedev 25.10.2012 - 17:39

Lea otras preguntas en las etiquetas