Converter dados em texto é uma necessidade comum a quase todos os programas. Afinal, raros são os que se comunicam com o usuário apenas com imagens ou sons. Ou que não precisam guardar nenhum dado.
Mesmo que se trate de um jogo, é provável que converta em texto, para apresentar para o usuário, pelo menos o número da fase, a quantidade de munição ou de vidas do personagem.
Os exemplos que dei foram todos de quantidades numéricas, pois são casos mais fáceis de entender. Porém, não se converte para texto apenas quantidades, mas sim, qualquer dado que seja processado pelo programa, como datas, horas e muitos outros, inclusive textos.
Mesmo sendo um tema super básico para os programadores, por vezes isso requer atenção e esforços maiores que o esperado.
Para pessoas leigas no assunto "programação", talvez nem se atentem para necessidade desse cuidado e trabalho dos programadores, mas vale a pena conhecer um pouco do assunto.
Essa conversão de dados para texto é geralmente chamada de "formatação". Ao invés de falar, por exemplo, que "vou 'converter em texto' em maiúsculas algo digitado pelo usuário", se fiz "vou 'formatar' em maiúsculas algo digitado pelo usuário".
Exemplo: "Número telefônico"
Um programador pode entender um número telefônico como um dado numérico e utilizar essa ideia no desenvolvimento de alguma solução de software. Pelo menos no Brasil isso faz sentido, afinal ao informarmos um número de telefone só falamos dígitos numéricos.
Efetivamente, por vezes informamos nosso telefone em algum programa ou site, e este reclama se colocarmos um "tracinho" ou um "espaço" no meio do número, mostrando uma mensagem "campo totalmente numérico", "este campo só aceita números" ou outra parecida.
Porém, na hora do programa ou site apresentar o número telefônico na tela ou em um impresso, provavelmente o fará como neste exemplo: 5551-2345
Aí você pode se você perguntar: "Porque não posso digitar o tracinho no número telefônico, mas ele é apresentado com o tracinho?"
Para responder, vamos por partes:
Primeiramente, não aceitar que o usuário digite o tracinho, pode ser apenas uma questão de escolha do programador sobre como o programa ou site deve funcionar. Não vou discutir neste artigo essa escolha do fictício programador.
A segunda parte do questionamento, aí sim, trata justamente do assunto que estou abordando, "formatação de dados".
No caso, apresentar com o tracinho pode se dizer que é o "certo a fazer". Ou, ao menos, o provavelmente mais adequado na maioria das vezes em que o ato de "leitura da informação por um humano" está envolvido.
Ler blocos menores de dígitos é muito mais fácil para a maioria das pessoas, e o tracinho ajuda a definir e separar esses tais blocos menores.
Então, um programador pode ter a ideia de apresentar blocos menores ainda, para facilitar ainda mais o usuário, e apresentaria o mesmo número assim: 55-51-23-45
São os mesmos dígitos e é fácil de ler porém, isso simplesmente não parece um número telefônico. E o motivo é simplesmente cultural.
Algumas formatações são definidas por lei. Seja gramatical ou jurídica. Outras, por senso comum.
É senso comum apresentar um número telefônico em 2 blocos de números. Todos esperam ver isso ao ler um número telefônico. Com isso o entendimento e a legibilidade ficam melhores.
Então, resumindo, formatar dados para leitura tem tudo a ver com capacidade humana entender os dados.
Exemplo de formato definido por lei: Quantidade monetária.
No Brasil a apresentação de uma quantidade de reais e centavos deve seguir um padrão. Por exemplo: R$ 1.234,56
Pode nos parecer óbvio, pois estamos acostumados a ler esse tipo de informação nesse formato, mas há leis e regras que ditam como deve ser: Iniciar com a letra "r" maiúscula, seguida por um cifrão, seguida por um espaço, seguido pela representação da quantidade em questão, com dois dígitos ao final para representar os centavos, separados por vírgula, e, em caso de valores grandes, pode ser utilizado o ponto para separar milhares, milhões e assim por diante.
Parece até regra demais para uma coisa tão simples, mas é necessário e todos nós sempre seguimos, naturalmente, pelo menos parte dessas regras sem reclamar. Pois já é natural para nós.
Porém, para o computador, para um programa, que não sabe nada de cultura e leis brasileiras, não é natural. Então o programador deve cuidar para que as regras de formatação corretas seja seguidas. Ou que sejam feitam adaptações coerentes.
Um exemplo de adaptação coerente seria, quando um programa apresenta uma coluna de valores em reais, o programador poderia escolher colocar o "R$" no topo da coluna, e nas linhas da coluna colocar os valores sem o "R$". A visualização fica mais leve e agradável, sem prejudicar a legibilidade e o entendimento.
Já falei muito da questão de apresentação de dados para leitura humana, mas também citei acima que dados também são formatamos serem guardados, armazenados.
Nesse caso a formatação pode ter vários motivos que não a legibilidade. Por exemplo, a padronização, a facilidade de processamento e a economia de espaço.
Uma data, por exemplo, pode ser formatada para leitura humana num formato extenso, como "14 de agosto de 2023", mas pode ser formatada para armazenamento como "2023-08-14", que além de ser menor que a opção em extenso, facilita na hora de ordenar várias datas. Na verdade poderia até ser formatada como "20230814", que é mais compacta ainda. Perde legibilidade humana, mas, nesse caso não é problema, pois esse dado, no exemplo, não será acessado por humanos e sim por programas que saberão, de acordo com programação adequada, que os primeiros 4 dígitos são referentes ao ano, os 2 seguintes, ao mês e os últimos 2, ao dia da data em questão.
Enfim, formatação é um assunto tão simples, mas com tandos desdobramentos, casos de uso, exceções e variações culturais, que acaba muitas vezes tomando um bom tempo e esforço para ser adequadamente tratado.
Mãos a obra programadores!
Se a maioria dos usuários sequer percebe esse esforço, é porque o trabalho de formatação está sendo, na maioria das vezes, bem feito.
Nenhum comentário:
Postar um comentário