Executando verificação de segurança...
5

result, temp, i, j, aux, num: O que o nome dessas variáveis têm em comum?

Durante seu processo inicial de aprendizagem em linguagens de programação, você talvez tenha se esbarrado com essas seguintes situações:

int num1 = 25, num2 = 45;
int result = num1 + num2

Ou quem sabe:

int num1 = 12;
int num2 = 54

int aux = num1;
num1 = num2;
num2 = aux;

É engraçado, pois, não sei é só comigo, mas eu vi o nome desses carinhas (e também de outros) em aulas de professores do meu curso técnico (inclusive professores diferentes), professores de cursos on-line e também em professores do meu atual curso superior.

Não me entrava na cabeça o fato de como pessoas diferentes, de Estados diferentes, culturas diferentes e com quase NADA em comum (muitas vezes nem o curso superior), tiravam esses nomes de variáveis na hora de me explicar programação em C.

Mas aí eu só acho que nunca entrou na cabeça por que nunca parei para pensar sobre! E conversando com amigos, lendo alguns livros e fóruns, eu talvez tenha uma teoria do porquê desses carinhas nos assombrarem 👻

🧮 1 + 1 = 11

Os lobos estão para os cachorros, assim como os matemáticos estão para os desenvolvedores (e também para o resto da Ciência da Computação). Nós viemos de uma linhagem e de um viés matemático e esse viés lógico e matemático está presente até nos dias de hoje!

Você possivelmente já percorreu uma matriz em linguagem C, por exemplo, utilizando meio que essa sintaxe:

for(int i = 0; i < 5; i++) {
    for(int j = 0; j < 5; j++)
        printf (" %d ", matrix[i][j]);
    printf ("\n");
}

Não lhe é familiar utilizar i para identificar linhas e j para colunas assim como vemos na matemática?

text

Tá bem... Dessa você provavelmente já sabia! Mas e as inúmeras vezes que utilizamos funções em linguagens de programação? Já parou para pensar sobre?

int square(int numberToSquare)
    return numberToSquare * numberToSquare;
    
square(2) // 4
f(x) = x²
f(2) = 4

☕️ O ano era 1969

Isso mesmo! O ano era 1969 e você estava, assim como está agora, lendo um post no TabNews, tomando um café, trabalhando de forma remota no meu Notebook Core i7 com 16GB de RAM e... Pera.. Na verdade... NÃO!

Pois bem, é importante relembrar que tudo era diferente naqueles tempos! Uma máquina, um computador, não tinha o mesmo poder de processamento e de memória como nossos computador contemporâneos!

Bem, nos tempos de hoje nos preocupados em otimizações de chamadas em bancos de dados, responsividade de um layout, a quantidade de render que seu component em React está fazendo, mas talvez a última coisa que você pense é: Quantos bytes o nome dessa variável vai ocupar em memória?

Para os que talvez não saibam (e também não é sua obrigação, mas é legal saber), um único byte é representado por oito bits. Dessa forma, um caractér é representado por 8 bits! Para você ter uma ideia, até esse momento de leitura temos 1965 caracteres!

Os programadores da época não tinham o luxo (sim, luxo) de aplicar um Clean Code por conta do poder de processamento e memória dos computadores da época.

🖥️ 1920 x 1080

Como é bom programar com dois monitores, não é? Imagine então com dois ultrawides, ou um monitor curvo, ou um monitor em vertical e outro em horizontal e... Bem, problemas de programadores contemporâneos, não é?

Mas, além da limitação técnica nos computadores, também havia a limitação nos periféricos. Não tínhamos o espectro de visualização que temos hoje! Eu me lembro até hoje de quando saímos dos 4:3 para os 16:9 e foi um boom incrível.

Você já deve saber onde quero chegar! O que era mais fácil de se visualizar?

int idThatReffersThisUser = 543;
// ou
int u = 543;

🕓 Quanto tempo tem o tempo?

Pode não parecer, mas o Ken Thompson - criador do UNIX, linguagem B e desenvolvedor na linguagem C - está vivo até hoje! Linus Torvalds, principal desenvolvedor do núcleo Linux, também está vivinho da silva. Assim como Bill Gates, ̶c̶o̶m̶p̶r̶a̶d̶o̶r̶, ops, "inventor" do Windows também!

O ponto que quero chegar é que, por mais que parece que estamos em um outro patamar (e de fato estamos), a ciência da computação em si é uma área muito nova e em constante evolução. Talvez nossos professores, que lá atrás aprenderam COBOL, Fortran, Pascal e quem sabe até Assembly, tenham trago esses paradigmas para os dias de hoje! E não é culpa deles, essa foi a forma que eles talvez aprenderam e nos passaram até hoje.

Mas isso não se prende aos professores, eu mesmo, quando atuei como monitor na disciplina de Linguagens e Técnicas de Programação, mesmo em um mundo completamente novo, utilizava das mesmas técnicas por serem certas para mim.

Conclusão

Bem, a conclusão que trago sobre esse mini documentário é que... Meio que não há conclusão! Não tenho fontes para quase nada do que escrevi, pois foram só meus pensamentos e nada aqui é verdade absoluta. O objetivo desse post é encontrar pessoas para debater sobre ou para analisarem que há um sentido no que disse aqui!

Agora um pequeno sermão! Caso você ainda utilize desses artifícios hoje em seu ambiente de aprendizagem ou de trabalho, seria bastante interessante aprender agora o que nossos antigos programadores não conseguiam implementar por conta de limitações: O Código Limpo.

Não foi culpa dos nossos veteranos os códigos escritos assim, mas com certeza é o nosso se continuarmos os escrevendo dessa maneira.

Carregando publicação patrocinada...
2

Eu sou daquele tempo em que precisavamos economizar memória para o nome das variáveis;
Aliás, esses nomes de variáveis eram considerados auto-explicativos:
R: para um retorno, resultado ou resposta.
T: para temporário.
t: para contagem de tempo.
i: para um indice.
C: para um contador dentro de uma subrotina.
X, Y, Z: para coordenadas.
N1, N2, N3: para armazenar números quaisquer.

Naquela época o programa precisava ser escrito de tal forma que ocupasse pouca memória e executasse rápido; às vezes a necessidade de executar mais rápido fazia com que escrevessemos programas sem blocos de repetição; mas com tudo repetido manualmente, como esses exemplos sem uso prático:

10 FOR i=1 TO 5
20 ?i
30 NEXT

esse primeiro exemplo ocupa 25 Bytes e executa mais devagar.

10 ?1
20 ?2
30 ?3
40 ?4
50 ?5

esse segundo ocupa 31 Bytes e executa mais rápido.

(a linguagem desses programas é o BASIC)
Ambos imprimem no monitor o seguinte resultado:

1
2
3
4
5

A observação é que naquela época a execução de um programa desses era tão lenta que nós podiamos perceber as linhas sendo impressas uma por uma no monitor.

1

Assim que você comentou sobre a tecnologia ao longo do tempo me veio o video to Daniel Shiffman do The Coding Train na cabeça acho que você e pessoas que curtem esse assunto vão gostar do conteúdo que ele tem feito brincando com Apple Basic num Apple II Plus.

Acho o conteúdo dele sensacional do ponto de vista didático, divertido e informativo. Eu particularmente, gasto horas assistindo videos dele.

1

Quantos bytes o nome dessa variável vai ocupar em memória?

Essa pergunta me lembrou de uma coisinha...

Ainda mais antigamente, para você ter algo perto de uma váriavel, era usar a memória RAM, e era pegar uma posição, pegar o valor, e mandar a RAM guardar.

E fica a pergunta: se pra fazer um contador, é aumentar o valor da váriavel e voltar uma linha, por quê um app que faz a mesma coisa gasta tanta memória sendo que ele só usa tipo 2 bytes?