Dicas para o desenvolvimento de um software – Parte 10

Dicas para o desenvolvimento de um software - Parte 10Olá, leitores. Quando iniciei a elaboração dessa série de artigos sobre dicas de desenvolvimento de um software, a intenção, na verdade, era produzir apenas quatro artigos. No entanto, com a sugestão de alguns leitores e com o aprendizado do dia-a-dia, volto com a décima parte dessa série abordando mais algumas recomendações técnicas. Here we go!

 

Alinhamento dos componentes da tela
Recentemente, recebi um e-mail de um desenvolvedor que encontrou problemas ao executar o software em computadores com diferentes resoluções. Segundo ele, quando a resolução era mais alta, os componentes ficavam todos bagunçados na tela do usuário. Para que eu pudesse ajudá-lo, ele também me enviou um código que realizava o redimensionamento automático dos componentes da tela conforme a resolução do computador. Essa é uma opção, mas, no meu ponto de vista, optar pelo alinhamento é melhor.
Alinhar os componentes na tela significa fixá-los em determinadas áreas. Por exemplo, o painel de pesquisa pode ser alinhado no topo da tela, a Grid de dados no centro e o painel de botões na parte inferior. Ao alterar o tamanho da tela, os componentes acompanharão o redimensionamento de forma que continuem corretamente distribuídos, sem necessariamente sofrer alterações no próprio tamanho. Em outras palavras, se o painel de botões está alinhado à parte inferior central (bottom-center), ele continuará no centro independente do tamanho da tela. No Delphi, geralmente trabalha-se com a propriedade Align em conjunto com a propriedade Anchors, útil para “ancorar” um componente em algum ponto da tela. Vale ressaltar que, para que isso seja possível, é necessário que os componentes estejam agrupados em um container, como um painel, um frame ou uma barra de ferramentas.

Propriedades de alinhamento do Delphi
Propriedades de alinhamento do Delphi

Por outro lado, nada impede que você limite o redimensionamento das telas da aplicação, configurando os parâmetros mínimo e máximo de altura e largura. Essa configuração evita que o visual de uma tela fique comprometido quando houver um redimensionamento fora do padrão.

 

Espaços em branco
Você conhece aquele tipo de usuário que coloca um, dois ou até três espaços em branco antes de começar a digitar? Eu já conheci! Pode parecer que não, mas os espaços em branco no início de um valor em um registro podem trazer algumas consequências. A primeira delas é a questão da consulta: em uma instrução SQL, se você utilizar uma condição LIKE com o caractere curinga somente à direita (por exemplo, “where Campo like ‘Texto%'”), a busca não funcionará para os registros que têm espaços no início. Esse tipo de consulta considera o início do valor exato, portanto, para que a consulta retorne os dados, o usuário terá que digitar os espaços em branco no início, assim como fez ao gravar o registro. Ruim, não?
A segunda consequência é o alinhamento em Grids e relatórios. Se há espaços à esquerda em alguns registros, surgirá um efeito de desalinhamento, como se a tela ou o relatório estivesse com uma falha visual:

Relatório com valores desalinhados

 

A terceira consequência envolve a soma da quantidade de caracteres. Talvez o desenvolver queira calcular a quantidade de caracteres de um nome para inseri-lo adequadamente em um cupom fiscal ou aplicar regras de abreviação. Mesmo não perceptível aos nossos olhos, os espaços em branco são contáveis, rsrs.
Para resolver este problema, as linguagens de programação geralmente trazem uma função para retirar espaços em branco à esquerda e à direita de uma string, chamada Trim. Essa função pode ser utilizada antes de um registro ser gravado, de modo que os valores sejam persistidos no banco de dados já sem os espaços desnecessários. Porém, é importante destacar que o Trim não retira espaços em excesso dentro de uma string. Para isso, é necessário desenvolver uma função específica que percorra todas as letras de uma string removendo os espaços repetidos.

 

Número máximo de caracteres e intervalo numéricos
Dica básica, bem básica, mas que muitas vezes passa por entre os dedos dos desenvolvedores. Quando você deixa de configurar o tamanho máximo em um campo e o usuário digita um valor maior do que o permitido, podem ocorrer duas situações: o valor é “cortado” e gravado pela metade no banco de dados, ou o usuário recebe uma exceção semelhante ao “string truncation” do Firebird. Erros dessa natureza são bastante comuns, já que o usuário não sabe o limite de caracteres que podem ser digitados em um campo. A definição do número máximo de caracteres pode ser realizada através das propriedades dos próprios componentes em tempo de projeto ou execução. No Delphi e C#, a propriedade se chama MaxLength. No Java, uma das alternativas é utilizar um Document personalizado, sobrescrevendo o método insertString.
Para valores numéricos a situação pode ser um pouco diferente. Suponha que você tenha um campo que represente a porcentagem de desconto em uma venda e esqueceu de estabelecer o intervalo entre 0% e 100%. Por um golpe de distração, o usuário digita 250% e grava os dados. Mesmo que seja um valor aceitável pelo banco de dados, não faz sentido que exista um desconto de 250%, concorda? Na verdade, o estabelecimento sairia no prejuízo se isso acontecesse, rsrs. Quando a porcentagem envolve cálculos importantes, é fundamental ter uma restrição da faixa de valores.

 

Constantes
Algumas vezes fui questionado sobre a finalidade de se utilizar constantes no código-fonte. Em uma delas, o desenvolvedor disse que sempre usou variáveis, pois a única diferença é que as constantes não permitem que o seu conteúdo seja alterado, e este não era o seu caso. Sim, ele está correto. Mas a questão é que as constantes têm um motivo por não aceitarem a alteração de valores, ou seja, serem read only (somente leitura).
Considere um software desenvolvido para uma indústria de móveis. Nós sabemos que em determinadas épocas do ano há uma variação do valor do IPI, certo? Também sabemos que o IPI é utilizado em vários pontos do software, como pedidos, vendas, orçamentos, cálculo de preços e margens de lucro. Para controlar isso, suponha que os desenvolvedores decidiram colocar o valor do IPI manualmente em todos esses pontos do software da seguinte forma:

var
  ValorIPI: real;
begin
  ValorIPI := 0.10; // 10%
  // operações com a variável ValorIPI
end;

 

Agora imagine que no mês seguinte o valor do IPI baixou para 5%. Espere… isso significa que os desenvolvedores terão que alterar este valor em cada ponto do software que o utiliza? E se esquecerem de alterá-lo no formulário de pedidos? Bom, se isso ocorrer, o orçamento será emitido com acréscimo de 5% e o pedido será faturado com acréscimo de 10%. Nem preciso dizer o problema que vai dar, não é?
Constantes são úteis para casos como este. Basta concentrar o valor em um único local e utilizar a constante que o representa. Utilizando o mesmo exemplo acima, poderíamos modificá-lo da seguinte maneira:

const
  CONSTANTE_VALOR_IPI = 0.10; // 10%
 
var
  ValorIPI: real;
begin
  ValorIPI := CONSTANTE_VALOR_IPI;
  // operações com a variável ValorIPI
end;

 

E por quê não posso utilizar uma variável? Não seria a mesma coisa?
Sim, seria, mas utilizar constantes garante que o valor nunca será alterado. Ao utilizar variáveis, corre-se o risco do seu conteúdo ser modificado por uma rotina qualquer e afetar os cálculos no software. Outra vantagem é a opção de criar uma classe exclusiva para guardar todas as suas constantes, facilitando a manutenção e compartilhando-as entre módulos. Em algumas empresas, os desenvolvedores criam constantes até para as mensagens de aviso e de confirmação que são exibidas na tela. Dessa forma, sempre haverá uma padronização das mensagens apresentadas ao usuário. Interessante!
Só para efeito de conhecimento, é comum encontrar constantes declaradas todas em maiúsculas. Essa é uma convenção utilizada normalmente por programadores Delphi.

 

Leitores, hoje fico por aqui!
Alguns tópicos da parte 11 já estão quase prontos!

Abraço!


Confira também as outras partes deste artigo:

Dicas para o desenvolvimento de um software – Parte 1
Dicas para o desenvolvimento de um software – Parte 2
Dicas para o desenvolvimento de um software – Parte 3
Dicas para o desenvolvimento de um software – Parte 4
Dicas para o desenvolvimento de um software – Parte 5
Dicas para o desenvolvimento de um software – Parte 6
Dicas para o desenvolvimento de um software – Parte 7
Dicas para o desenvolvimento de um software – Parte 8
Dicas para o desenvolvimento de um software – Parte 9
Dicas para o desenvolvimento de um software – Parte 10
Dicas para o desenvolvimento de um software – Parte 11


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

6 comentários

  1. muito bom esta postagem de programação, pra mim que estou começando agora, esta me ajudando muito, espero poder ver mais postagens iguais a essa daqui pra frente, parabens Andre, continue assim, grande abraço.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.