Cosa hanno fatto i programmatori prima dell'ambito variabile, dove tutto è globale?

Quindi, ho a che fare con un linguaggio apparentemente archiac (chiamato PowerOn) in cui ho un metodo principale, alcuni tipi di dati con cui definire le variabili e ho la capacità di avere sotto-procedure (essenzialmente metodi nulli) che non restituiscono un tipo né accetta alcun argomento. Il problema qui è che TUTTO è globale. Ho letto di questo tipo di lingue, ma la maggior parte dei libri prende l'approccio "Ok, usiamo un cavallo e una carrozza, ma ora, ecco un'auto quindi impariamo a lavorare su QUELLO!" Non rivivremo MAI quei giorni " . Devo ammettere che la mente sta lottando per pensare al di fuori di portata e portata .

Bene eccomi qui. Sto cercando di capire come gestire al meglio nient'altro che variabili globali attraverso diversi metodi aperti . Sì, anche gli iteratori per i forloop devono essere definiti a livello globale, che mi ritrovo a riciclare in diverse parti del mio codice.

La mia domanda: per coloro che hanno questo tipo di esperienza, come hanno fatto i programmatori a gestire una grande quantità di variabili in un campo di gioco globale? Sento che è appena diventato un trucco di giocoleria mentale, ma sarei interessato a sapere se ci fossero approcci noti.

Avrai bisogno di una sorta di trucchi di contabilità mentale (convenzioni di denominazione, ecc.) Per mantenerlo dritto. Inoltre, documento, documento, documento. Dal momento che tutte le variabili sono globali, se possibile puoi avere un unico documento con tutte elencate.

Cerca di avere un numero limitato di variabili che usi sempre per i provvisori e ricorda che SONO TEMPORANEI. Riutilizzando costantemente gli stessi, avrai l'abitudine di tenere traccia di dove sono validi o meno.

Inoltre, vuoi guardare la documentazione e assicurarti di sapere quanto possono essere lunghi i nomi delle variabili e quanti caratteri sono effettivamente unici. Non so NIENTE su PowerOn, ma se è abbastanza arcaico da avere solo un ambito globale, è possibile che abbia una lunghezza univoca limitata sugli identificatori.

Ho già visto cose con identificatori lunghi, ma i cui identificatori erano unici nei primi 8 caratteri. Quindi potresti avere RonnyRayGun e RonnyRayBlaster e in realtà sono la variabile SAME. In questi casi, consiglio di mantenere i nomi delle variabili al di sotto del limite "univoco", in modo da ridurre le probabilità di collisione accidentale.

Dizionario dei dati

In un repository centrale (di solito l'ufficio del programmatore principale), c'era un raccoglitore a fogli mobili, che conteneva una pagina per ogni variabile globale. La pagina ha dato il nome, la sua definizione, il suo scopo e quali routine lo hanno impostato o utilizzato.

I primi sistemi embedded con RAM microscopica presentavano un problema simile e una soluzione simile. Il programmatore principale ha mantenuto la mappa RAM principale, fino ai singoli byte, mostrando quale RAM è stata utilizzata da quali moduli per quali scopi. I programmatori che avevano bisogno di un'allocazione RAM dedicata sono andati al programmatore principale, che, dopo aver discusso della questione, ha fatto la voce del notebook appropriata e ha dato al ragazzo la sua RAM. (Non volevi essere nei panni del programmatore che ha preso un byte RAM senza cancellarlo con il programmatore principale. Fidati di me su questo.)

Questo problema si presentava anche quando i programmatori dovevano costruire sistemi di grandi dimensioni nelle prime versioni di BASIC. Mi è apparso personalmente mentre utilizzavo un gestore di "database" molto primitivo chiamato Info (prodotto di Henco, Inc. del New Jersey - HOPEFULLY ormai scomparso!). Entrambe queste lingue avevano un vocabolario con nome variabile molto limitato.

L'ascesa di linguaggi di programmazione con ambito di blocco coincise con l'avvento di macchine più grandi e veloci, e non è una coincidenza. I primi computer avevano la RAM misurata in MB, kB o addirittura in byte; semplicemente non vi era alcuna possibilità di avere così tante variabili che sarebbero confuse quando il programma diventasse grande, perché i programmi non erano mai così grandi . I progressi nei linguaggi di programmazione venivano generalmente fatti quando le persone riconoscevano che le loro vecchie abitudini di programmazione non aumentavano quando l'arena si ingrandiva molto; l'ambito del blocco è stato inventato come meccanismo di difesa per i programmatori contro la propria memoria limitata.

Il calcolo era anche un'attività molto più rarefatta ed esotica quando i comoputer erano incredibilmente costosi e potrebbe anche essere che solo individui particolarmente inclini alla matematica e ingegnosi diventassero programmatori (sebbene tali confronti siano poco pratici da testare e certamente politicamente incendiari). All'inizio, il software veniva solitamente spedito gratuitamente con un computer per convincere le persone ad acquistarlo in primo luogo; l'idea che gli utenti istituzionali avrebbero persino tentato di scrivere i propri programmi all'inizio era sconosciuta.

Mio Dio, è stato molti anni fa (ricordi gorgoglianti :)).

Non conosco la lingua a cui ti riferisci, ma in generale ci siamo adattati a ciò che avevamo. Non è stato davvero un grosso problema. Dovevi prestare maggiore attenzione ai nomi var che spesso contenevano (in breve, in quei giorni il numero di byte era prezioso) riferimento a sub o funzione, come mIORead1se avessi un gestore per leggere i dati da un file 1, o se avessi vari contrari come io, j, k ecc. che con il tuo stesso sistema sapevi a cosa servivano, se potessero essere riutilizzati e così via. Era più hardcore (allora non c'erano caschi o guanti) :-)

Questo è abbastanza simile alla programmazione dei PLC, anche se i moderni PLC ora consentono di avere "tag" (ovvero variabili) che sono locali in un programma. Tuttavia, molte persone programmano semplicemente usando tutti i tag globali.

Ho scoperto che, se hai intenzione di farlo, devi utilizzare una convenzione di denominazione strutturata. Per esempio: Motor1_DriveContactor_Run. Se la tua lingua capita di supportare strutture (a volte conosciute come tipi definiti dall'utente), puoi anche usarle per creare una gerarchia di dati strutturata, come:Motor[1].DriveContactor.Run .

Ciò mantiene tutto organizzato, e di solito l'intellisense è abbastanza decente da aiutarti.

In realtà ho imparato a programmare in una lingua chiamata Authorware, dove tutto era globale. Fortunatamente, aveva array e dopo un certo punto qualcosa chiamato Lists, che erano simili agli oggetti generici.

Un programma Authorware in realtà aveva una struttura fisica (Authorware era basato su una metafora del diagramma di flusso) e il suo linguaggio di scripting era basato sul vecchio stile Pascal. Ciò che abbiamo fatto è stato quello di mettere in relazione la struttura fisica con gli indici di una matrice, e spesso gli indici della matrice contengono elenchi che tratteremmo come oggetto locale per il pezzo fisico che stavamo usando.

Authorware è stato progettato per l'eLearning, quindi una delle icone che avevamo era una Pagina. Le pagine sarebbero allegate a un Framework. Quindi, per la Pagina 1, esamineremmo alcuni array nell'indice 1 (Authorware era 1 indicizzato) ed estrarre i dati per quella pagina, che sarebbe memorizzata in un Elenco che fungerebbe da pseudo-oggetto. La Pagina avrebbe quindi una logica che estrarrebbe le "proprietà" dell'oggetto per nome. Se non hai nulla come gli oggetti, ma hai array, puoi semplicemente avere una convenzione su quali dati vanno dove.

Non è poi così diverso da quello che facciamo quando recuperiamo i dati da un database ed eseguiamo l'iniezione delle dipendenze, tranne per il fatto che tutto è veramente globale, e stai semplicemente scegliendo di mettere tutto in piccole scatole e guardare solo quello / i che sei interessato adesso.

A seconda di ciò che stai cercando di fare e di ciò che la tua lingua supporta, questo potrebbe aiutarti almeno a scomporre le cose in blocchi più gestibili.

Quando ero all'università ci hanno insegnato a lungo "Il problema delle variabili globali" - una raccolta di bug e problemi di mantenimento del codice causati da molte variabili globali.

Alcune variabili sono più pericolose di altre.

Sicuro : variabili che non influiscono sul flusso di controllo, ad esempio LastName

Pericoloso : qualsiasi variabile che influisce sul flusso di controllo del programma, ad esempio DeliveryStatus

Prima il più pericoloso:

• Stato composto (modalità e modalità secondaria)
• Valori composti (totale, totale parziale)
• Stato singolo (modalità)
• Valori singoli (conteggio)

Per evitare il "problema delle variabili globali" è necessario

• Documenta ogni variabile e funzione.
• Tieni le variabili correlate vicine (con il codice che le utilizza) nella stessa sezione del codice sorgente.
• Nascondi le variabili "pericolose", in modo che altri programmatori non siano a conoscenza della loro esistenza. Evita di usarli direttamente, specialmente in altre sezioni del codice.
• Fornire funzioni che leggono / scrivono variabili pericolose (quindi non è necessario che altri programmatori).

Per strutturare il codice , quando non è disponibile alcuna struttura nella lingua, utilizzare i commenti e le convenzioni di denominazione:

/* --------------------------- 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";

Non so come hanno fatto.

Ma penso che i moderni linguaggi OOP abbiano avuto un problema molto simile riguardo alla collisione dei nomi .

La soluzione sta adottando lo spazio dei nomi . È un concetto astratto, ma ampiamente adottato da diverse implementazioni (pacchetti Java, spazio dei nomi .NET, moduli Python).

Se la lingua che stai utilizzando non ha limitazioni troppo strette sulla lunghezza dei nomi, puoi applicare lo spazio dei nomi a una buona denominazione delle variabili.

Quindi il nome della variabile rappresenta anche l'ambito della variabile.

Prova a definire un modello di denominazione come questo: order_detail_product_code, order_detail_product_unit_price. O per i contatori o gli swap temporanei: tmp_i, tmp_swap.

Nelle lingue tutte le variabili sono globali (ne ho usate una coppia) che usavamo per usare una convenzione di denominazione delle variabili. Ad esempio: se in realtà volessi usare una variabile come globale, potrei usare il prefisso "m_" o "_". Naturalmente questo si basa ancora sugli sviluppatori per avere questa disciplina