Postagem em destaque

Código Limpo: Nomes Significativos

Imagem
Às vezes fico com um assunto na cabeça por semanas, até achar uma situação ou um exemplo que esclareça a situação. Explico: estava querendo já a algum tempo escrever sobre boas práticas de programação, e pensei em iniciar por "Nomes Significativos", para seguir a nomenclatura utilizada pelo ótimo livro Código Limpo , de Robert C. Martin.  Entretanto, ficava sempre amarrado em exemplos que pareciam ser bons, mas que ainda eu não tinha visto a utilidade prática.  Antes de continuar preciso explicar que tenho um hábito de anotar num bloco de papel todas as ideias que surgem, pois elas desaparecem com a mesma velocidade que aparecem. Para isso tenho um bloco e caneta na mesa de cabeceira (além de um no banheiro), pois esses são os lugares onde tenho mais ideias... Vai entender... Semana passada, estava com um problema bem complicado e tive uma ideia: "vou criar uma variável para indicar que quando um arquivo tiver um certo tamanho deve gravar algumas informações no log. Pois

Artigo 6 - Bug do ano 2000

(Publicado originalmente entre 1994/95)

Bug pode ser traduzido como problema, erro, defeito. Só que o do final deste milênio será provavelmente o maior de todos os tempos. O problema todo começou por falta de planejamento ou visão. Pois as datas, dentro dos programas, eram armazenadas no seguinte formato: dd/mm/aa. Ou seja, dois dígitos para o dia (correto), dois dígitos para o mês (correto) e dois dígitos para o ano (econômico). Econômico porque a até alguns atrás o espaço para armazenamento (tanto em memória quanto no disco rígido era extremamente caro). A data no formato dd/mm/aa precisa de 25% menos espaço do que no formato dd/mm/aaaa. Um registro que tenha 10 datas no formato dd/mm/aa, precisará de mais 20 dígitos para ficar no formato dd/mm/aaaa. Se existirem 100 mil registros, o arquivo irá crescer 2 milhões de dígitos.

Por exemplo, quando num sistema (programa), que armazene as datas no formato dd/mm/aa, entramos com a data de 15 de Janeiro de 2000, o sistema irá guardá-la como 15/01/00. Se fôssemos tirar um relatório com data maior que 31/12/98 o sistema não mostraria essa data de 15/01/00, porque (para o computador) 15/01/00 é menor que 31/12/98.

Existem soluções como a que um engenheiro de Joinville apresentou, que consistia em utilizar os meses de 13 a 24 para representar os anos de 2000 a 2099, 25 a 36 para os anos de 2100 a 2199, e assim até os meses de 85 a 96 para os anos de 2600 a 2699.

Para se corrigir um sistema de tamanho médio, como um Sistema Comercial Integrado (contas a pagar e a receber, estoque, faturamento e banco), de cerca de 100 mil linhas de programa, a um custo por linha de código de US$ 0,70, gasta-se US$ 70.000,00. Pelo menos alguém saiu ganhando nesta situação: os programadores. Que já estão, em alguns casos, até negando serviço. Além disso, o preço por linha de código a ser verificado está subindo sem parar. Estima-se que até o ano 2000 o preço por linha de código chegue a US$ 7,00, dez vezes o preço atual.

E não é só no ano 2000 que os programas começarão a acusar o problema. Desde já, os programas precisam estar preparados, pois num financiamento de 5 anos (60 meses), as datas que forem lançadas deveriam estar no formato dd/mm/aaaa, caso contrário, essa pessoa passaria a ter um dívida de 100 anos!

Comentários

Postagens mais visitadas deste blog

Netflix não mostra ícone de streaming

Google Hacking

FTP não funciona no PHP