Che cosa hanno fatto i programmatori prima dell'ambito delle variabili, dove tutto è globale?

40

Quindi, sto avendo a che fare con un linguaggio apparentemente arcico (chiamato PowerOn) dove ho un metodo principale, alcuni tipi di dati per definire le variabili con, e ho la capacità di avere sottoprocedure (essenzialmente metodi void) che non restituisce un tipo e non accetta alcuna argomentazione. Il problema qui è che TUTTO è globale. Ho letto di questi tipi di lingue, ma la maggior parte dei libri ha l'aproach "Ok, usiamo un cavallo e un cariage, ma ora, ecco una macchina, quindi impariamo come si lavora su THAT! " Non riviveremo MAI quei giorni ". Devo ammettere che la mente fatica a pensare al di fuori dell'ambito e dell'estensione .

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 for loops devono essere definiti globaly, che mi ritrovo a riciclare in diverse parti del mio codice.

La mia domanda: per coloro che hanno questo tipo di esperienza, in che modo i programmatori hanno a che fare con una grande quantità di variabili in un campo di gioco globale? Mi sembra che sia diventato un gioco di giocoleria mentale, ma io sarebbe interessato a sapere se ci sono stati noti approcci.

    
posta Chad Harrison 23.10.2012 - 18:20
fonte

9 risposte

44

Avrai bisogno di qualche tipo di trucchetto mentale (convenzioni di denominazione, ecc.) per mantenerlo dritto. Inoltre, documento, documento, documento. Poiché tutte le variabili sono globali, disponi di un singolo documento con tutti i nomi elencati, se possibile.

Prova ad avere un piccolo numero 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 dare un'occhiata alla documentazione e assicurarti di sapere per quanto tempo i nomi delle variabili possono essere e quanti caratteri sono effettivamente unici. Non so nulla di PowerOn, ma se è abbastanza arcaico da avere solo un ambito globale, allora è possibile che abbia una lunghezza univoca limitata sugli identificatori.

Ho già visto cose con identificatori lunghi, ma i cui identificatori erano unici solo nei primi 8 caratteri. Quindi potresti avere RonnyRayGun e RonnyRayBlaster e sono in realtà la variabile SAME. In questi casi, ti consiglio di mantenere i nomi delle variabili sotto il limite "univoco", in modo che sia meno probabile che vi sia una collisione accidentale.

    
risposta data 23.10.2012 - 18:31
fonte
53

Dizionario 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 fornito il nome, la sua definizione, il suo scopo e le routine impostate o utilizzate.

I primi sistemi embedded con RAM microscopica avevano un problema simile e una soluzione simile. Il programmatore principale ha mantenuto la mappa RAM master, fino ai singoli byte, mostrando quale RAM è stata utilizzata da quali moduli per quali scopi. I programmatori che avevano bisogno di un'assegnazione di RAM dedicata andarono al programmatore principale, che, dopo aver discusso la questione, fece la voce appropriata del taccuino e diede 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.)

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

    
risposta data 23.10.2012 - 18:45
fonte
8

L'ascesa dei linguaggi di programmazione con ambito di blocco ha coinciso con l'avvento di macchine più veloci e più grandi e non è una coincidenza. I primi computer avevano RAM misurata in MB, kB o anche in byte; semplicemente non c'era alcuna opportunità di avere così tante variabili da essere confuse quando il programma diventava grande, perché i programmi non avevano mai quel grande . I progressi nei linguaggi di programmazione venivano fatti di solito quando le persone riconoscevano che le loro vecchie abitudini di programmazione non aumentavano quando l'arena diventava molto più grande; il blocco di ambito è stato inventato come meccanismo di difesa per i programmatori contro la loro memoria limitata.

Anche l'informatica era un'attività molto più rarefatta ed esotica quando i comoputers erano incredibilmente costosi, e potrebbe benissimo essere che solo individui particolarmente inclini alla matematica e ingegnosi diventassero programmatori in primo luogo (sebbene tali confronti siano poco pratici da testare, e certamente politicamente incendiaria). Nei primi tempi, il software veniva solitamente spedito gratuitamente con un computer per convincere la gente a comprarlo in primo luogo; All'inizio, il pensiero che gli utenti istituzionali avrebbero persino tentato di scrivere i propri programmi era sconosciuto.

    
risposta data 23.10.2012 - 18:31
fonte
4

My gosh, che è molti anni fa (bubbling memories:)).

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

    
risposta data 23.10.2012 - 18:30
fonte
3

Questo è molto simile alla programmazione PLC, anche se i moderni PLC ora consentono di avere "tag" (cioè variabili) locali per un programma. Tuttavia, molte persone programmano solo l'utilizzo di tutti i tag globali.

Ho trovato, se hai intenzione di farlo, devi usare una convenzione di denominazione strutturata. Ad 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 strutturati, come ad esempio: Motor[1].DriveContactor.Run .

Ciò mantiene tutto organizzato, e solitamente l'intellisense è abbastanza decente da aiutarti a lungo.

    
risposta data 23.10.2012 - 18:42
fonte
2

In realtà ho imparato a programmare in un linguaggio chiamato Authorware, dove tutto era globale. Fortunatamente, aveva Array e dopo un certo punto qualcosa chiamato Elenchi, che erano simili a 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 Pascal. Quello che abbiamo fatto è stato mettere in relazione la struttura fisica con gli indici di una matrice, e spesso gli indici di array avrebbero contenuto elenchi che avremmo trattato come un oggetto locale per il pezzo fisico che stavamo usando.

Authorware è stato progettato per l'eLearning, quindi una delle icone che avevamo era una Page. Le pagine verrebbero allegate a un Framework. Quindi, per la prima pagina, cercheremmo in alcuni array nell'indice 1 (Authorware era 1indicizzato) e estrassero i dati per quella pagina, che verrebbero archiviati in una lista che si comporterebbe come uno pseudo-oggetto. La pagina avrebbe quindi una logica che estrae le "proprietà" dell'oggetto per nome. Se non hai nulla come Oggetti, ma hai Matrici, 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, eccetto che tutto è veramente globale, e tu stai semplicemente scegliendo di mettere tutto in piccole scatole e guardare solo a quello (s) ) ti preoccupa adesso.

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

    
risposta data 24.10.2012 - 02:11
fonte
1

Quando ero all'università ci hanno insegnato a lungo su "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 influenzano il flusso di controllo ad es. Cognome

Pericoloso : qualsiasi variabile che influenza il flusso di controllo del programma, ad es. DeliveryStatus

Prima il più pericoloso:

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

Per evitare il "problema delle variabili globali" è necessario

  • Documenta ogni variabile e funzione.
  • Mantieni le variabili correlate vicine (con il codice che le usa) nella stessa sezione del codice sorgente.
  • Nascondi le variabili "pericolose", quindi altri programmatori non sanno della loro esistenza. Evita di utilizzarli direttamente, specialmente in altre sezioni del codice.
  • Fornisci funzioni che leggono / scrivono variabili pericolose (quindi non è necessario che altri programmatori).

Per strutturare il tuo codice , quando nessuna struttura è disponibile nella lingua, utilizza 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";
    
risposta data 14.06.2016 - 16:19
fonte
0

Non so come hanno fatto.

Ma penso che i moderni linguaggi OOP presentassero un problema molto simile per quanto riguarda la collisione sui nomi .

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

Se la lingua che stai utilizzando non ha limiti troppo stretti 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 uno schema di denominazione come questo: order_detail_product_code , order_detail_product_unit_price . Oppure per i contatori o gli scambi temporanei: tmp_i , tmp_swap .

    
risposta data 24.10.2012 - 11:31
fonte
0

Nelle lingue tutte le variabili sono globali (ne ho usato un paio) abbiamo usato una convenzione di denominazione delle variabili. Ad esempio: se volessi effettivamente utilizzare una variabile come globale, potrei usare il prefisso "m_" o "_". Naturalmente questo si basa ancora sugli sviluppatori per avere questa disciplina

    
risposta data 25.10.2012 - 17:39
fonte

Leggi altre domande sui tag