O que os programadores fizeram antes do escopo da variável, onde tudo é global?

40

Então, eu estou tendo que lidar com uma linguagem aparentemente arquiática (chamada PowerOn) onde eu tenho um método principal, alguns tipos de dados para definir variáveis com, e tem a capacidade de ter subprocessos (essencialmente métodos vazios) que não devolve um tipo nem aceita quaisquer argumentos. O problema aqui é que TUDO é global. Eu li sobre esse tipo de linguagem, mas a maioria dos livros usa a abordagem "Ok, nós usamos um cavalo e cariage, mas agora, aqui está um carro, então vamos aprender como trabalhar nisso! " NUNCA vamos reviver aqueles dias ". Tenho que admitir, a mente está lutando para pensar fora do escopo e extensão .

Bem, aqui estou eu. Eu estou tentando descobrir como gerenciar melhor nada além de variáveis globais em vários métodos open . Sim, até mesmo os iteradores para for loops precisam ser definidos globalmente, o que eu me encontro reciclando em diferentes partes do meu código.

Minha pergunta: para aqueles que têm esse tipo de experiência, como os programadores lidam com uma grande quantidade de variáveis em um campo global? Eu sinto que se tornou um truque de malabarismo mental, mas eu estaria interessado em saber se havia alguma abordagem conhecida.

    
por Chad Harrison 23.10.2012 / 18:20
fonte

9 respostas

44

Você precisará de algum tipo de truque de escrituração mental (convenções de nomenclatura etc.) para mantê-lo correto. Além disso, documento, documento, documento. Como todas as variáveis são globais, tenha um único documento com todas elas listadas, se puder.

Tente ter um pequeno número de variáveis que você sempre usa para temporários, e lembre-se de que ELES SÃO TEMPORÁRIOS. Ao constantemente reutilizar os mesmos, você terá o hábito de saber onde eles são válidos ou não.

Além disso, você deseja examinar a documentação e verificar quanto tempo os nomes das variáveis podem ser e quantos caracteres são realmente exclusivos. Não sei NADA sobre o PowerOn, mas se for arcaico o suficiente para ter apenas escopo global, então é possível que ele tenha uma duração limitada de exclusividade em identificadores.

Já vi coisas antes com identificadores longos, mas cujos identificadores eram únicos nos primeiros 8 caracteres. Então você poderia ter RonnyRayGun e RonnyRayBlaster e eles são na verdade a variável SAME. Nesses casos, recomendo manter os nomes de variáveis sob o limite "exclusivo", para que você tenha menor probabilidade de colidir acidentalmente.

    
por 23.10.2012 / 18:31
fonte
53

Dicionário de dados.

Em um repositório central (geralmente o escritório do programador principal), havia um fichário de folhas soltas, que continha uma página para cada uma das variáveis globais. A página deu o nome, sua definição, sua finalidade e quais rotinas o definiram ou usaram.

Sistemas embarcados antigos com memória RAM microscópica tiveram um problema semelhante e uma solução semelhante. O programador principal manteve o mapa de RAM principal, até os bytes individuais, mostrando qual RAM foi usada por quais módulos para quais fins. Os programadores que precisavam de uma alocação de RAM dedicada foram para o programador principal, que, depois de discutir o assunto, fez a anotação adequada no notebook e deu ao cara sua memória RAM. (Você não queria ficar no lugar do programador que pegou um byte de RAM sem limpá-lo com o programador principal. Confie em mim.)

Esse problema também apareceu quando os programadores tiveram que construir grandes sistemas nas primeiras versões do BASIC. Ele apareceu para mim pessoalmente enquanto usava um gerenciador de banco de dados muito primitivo chamado Info (produto da Henco, Inc. de New Jersey - HOPEFULLY, agora muito tempo!). Ambas as linguagens tinham um vocabulário de nome de variável muito limitado.

    
por 23.10.2012 / 18:45
fonte
8

O surgimento de linguagens de programação com escopo de bloco coincidiu com o advento de máquinas maiores e mais rápidas, e isso não é coincidência. Os primeiros computadores tinham RAM medida em MB, kB ou até mesmo em bytes; simplesmente não havia oportunidade de ter tantas variáveis que ficariam confusas quando o programa se tornasse grande, porque os programas nunca eram tão grandes . Os avanços nas linguagens de programação geralmente eram feitos quando as pessoas reconheciam que seus antigos hábitos de programação não aumentavam quando a arena se tornava muito maior; O escopo de blocos foi inventado como um mecanismo de defesa para programadores contra sua própria memória limitada.

A computação também era uma atividade muito mais rarefeita e exótica quando os comopagistas eram fantasticamente caros, e pode ser que somente indivíduos particularmente inclinados e engenhosos se tornassem programadores em primeiro lugar (embora tais comparações sejam impraticáveis para testar, e certamente politicamente incendiário). Nos primeiros dias, o software era geralmente enviado gratuitamente com um computador, a fim de convencer as pessoas a comprá-lo em primeiro lugar; o pensamento de que os usuários institucionais tentariam escrever seus próprios programas era desconhecido a princípio.

    
por 23.10.2012 / 18:31
fonte
4

Meu Deus, isso é há muitos anos (memórias borbulhantes:)).

Eu não sei a língua que você se refere, mas em geral nos adaptamos ao que tínhamos. Não foi realmente um grande problema. Você precisava prestar mais atenção aos nomes de var que geralmente continham (na forma abreviada, naqueles dias em que o número de bytes era precioso) referência a sub ou função, como mIORead1 se você tivesse um manipulador para ler dados de um arquivo 1 ou você tinha vários contadores como i, j, k, etc., que pelo seu próprio sistema você sabia para que serviam, se eles poderiam ser reutilizados e assim por diante. Foi mais hardcore (sem capacetes ou luvas na época): -)

    
por 23.10.2012 / 18:30
fonte
3

Isso é bem parecido com a programação de PLC, embora os CLPs modernos agora permitam que você tenha "tags" (também conhecidas como variáveis) que são locais para um programa. Ainda assim, muitas pessoas simplesmente programam usando todas as tags globais.

Descobri que, se você for fazer isso, precisará usar uma convenção de nomenclatura estruturada. Por exemplo: Motor1_DriveContactor_Run . Se o seu idioma suportar estruturas (às vezes conhecidas como tipos definidos pelo usuário), você também poderá usá-las para criar uma hierarquia de dados estruturados, como: Motor[1].DriveContactor.Run .

Isso mantém tudo organizado, e geralmente o intellisense é decente o suficiente para ajudá-lo.

    
por 23.10.2012 / 18:42
fonte
2

Eu realmente aprendi a programar em uma linguagem chamada Authorware, onde tudo era global. Felizmente, ele tinha Arrays e, depois de um certo ponto, algo chamado Lists, que eram semelhantes aos objetos genéricos.

Um programa Authorware na verdade tinha uma estrutura física (o Authorware era baseado em uma metáfora do fluxograma), e sua linguagem de script era baseada no estilo antigo Pascal. O que fizemos foi relacionar a estrutura física com os índices em um Array, e muitas vezes os índices Array conteriam Lists que trataríamos como um objeto local para a parte física que estávamos usando.

O Authorware foi projetado para eLearning, então um dos ícones que tínhamos era o Page. Páginas seriam anexadas a um Framework. Assim, para a Página 1, procuraríamos em algum Array no índice 1 (o Authorware era indexado em 1) e extraímos os dados para essa página, que seriam armazenados em uma Lista que atuaria como um pseudo-objeto. A página teria então uma lógica que extrairia as "propriedades" do objeto pelo nome. Se você não tem nada como Objetos, mas tem Arrays, pode simplesmente ter uma convenção de quais dados vão para onde.

Não é tão diferente do que fazemos quando recuperamos dados de um banco de dados e executamos a injeção de dependência, exceto que tudo é realmente global, e você está simplesmente optando por colocar tudo em pequenas caixas e olhar apenas para as (s) ) você está preocupado com agora.

Dependendo do que você está tentando fazer e do seu idioma, isso pode ajudá-lo, pelo menos, a dividir as coisas em partes mais fáceis de gerenciar.

    
por 24.10.2012 / 02:11
fonte
1

Quando eu estava na universidade, aprendemos muito sobre "O Problema da Variável Global" - uma coleção de bugs e problemas de manutenção de código causados por muitas variáveis globais.

Algumas variáveis são mais perigosas que outras.

Seguro : Variáveis que não afetam o fluxo de controle Sobrenome

Perigoso : Qualquer variável que afeta o fluxo de controle do programa, e. DeliveryStatus

Primeiro mais perigoso:

  • Status composto (modo e submodo)
  • Valores compostos (total, sub-total)
  • Status único (modo)
  • Valores únicos (contagem)

Para evitar o "problema de variável global", você precisa

  • Documente cada variável e função.
  • Mantenha as variáveis relacionadas juntas (com o código que as usa) na mesma seção do código-fonte.
  • Esconda as variáveis "perigosas", para que outros programadores não saibam de sua existência. Evite usá-los diretamente, especialmente em outras seções do código.
  • Fornece funções que lêem / gravam variáveis perigosas (portanto, outros programadores não precisam).

Para estruturar seu código , quando nenhuma estrutura estiver disponível no idioma, use comentários e convenções de nomenclatura:

/* --------------------------- 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";
    
por 14.06.2016 / 16:19
fonte
0

Não sei como eles fizeram.

Mas acho que as linguagens OOP modernas tiveram um problema muito semelhante em relação à colisão de nomes .

A solução está adotando o namespace . É um conceito abstrato, mas amplamente adotado por várias implementações (pacotes Java, namespace .NET, módulos Python).

Se o idioma que você está usando não tiver uma limitação muito restrita sobre o comprimento de nomenclatura, você poderá aplicar o namespace a uma boa nomenclatura de variável.

Portanto, o nome da variável também representa o escopo da variável.

Tente definir um padrão de nomenclatura como este: order_detail_product_code , order_detail_product_unit_price . Ou para os contadores ou swaps temporários: tmp_i , tmp_swap .

    
por 24.10.2012 / 11:31
fonte
0

Em idiomas onde todas as variáveis são globais (usei um par), costumávamos usar uma convenção de nomenclatura de variável. Por exemplo: se eu realmente quisesse usar uma variável como global, poderia usar o prefixo "m_" ou "_". Claro que isso ainda depende dos desenvolvedores para ter essa disciplina

    
por 25.10.2012 / 17:39
fonte

Tags