CARACTERÍSTICAS DE UM BOM PROGRAMA I – DA CERTEZA A - Se um programa não estiver certo ele não cumpre as suas finalidades.

B - Um programa certo, além de fazer o que deve, tem que não fazer o que não deve. Por exemplo: Ao calcular a área do triângulo de lados 4, 1, 1; o programa deve dizer que os lados não formam um triângulo e não dar um valor como resposta. Para isto, devemos sempre estabelecer o domínio de validade dos dados de Entrada do algoritmo e testar a validade da desses dados. C - Não é fácil fazer um programa certo, pois não há técnica conhecida que garanta a exatidão de um programa. Podemos mostrar que um programa está errado, mas não podemos mostrar que está 100% certo até que todos os testes possíveis tiverem sido feitos. As consistências, tanto de dados como do programa, deverão estar restritas as necessidades dos mesmos. Excesso de consistências e consistências que consistem outras consistências não agregam nada ao programa, fazem ele ficar mais lento e só servirão para proliferarem bugs e falhas no mesmo. Após a elaboração do programa passamos à fase de depuração, que é quando tentamos descobrir erros no mesmo. Existem técnicas para se testar um programa e abaixo damos algumas dicas: 1) Um programador nunca deve testar seu próprio programa, pois o teste é uma tarefa destrutiva e o programador geralmente não gosta de destruir o que fez. Além do mais ele já sabe perfeitamente como operar e como lançar os dados no programa o que impede que ele teste o comportamento do mesmo no caso de faltar lançar determinados dados ou lançar dados inválidos ou de outra forma. Isto pode omitir uma serie de possíveis bugs que estejam ocultos ou que somente se manifestam em uma determinada situação. 2) Um teste de um programa tem sucesso quando se acha um erro. Não tente mostrar que o programa está certo, pois isso, além de ser uma tarefa impossível, irá mascarar um problema que se manifestará futuramente comprometendo a credibilidade do sistema. 3) Teste "caixa preta": É quando examinamos um programa por suas especificações, sem olhar o código. Ao realizar um teste, tentamos explorar os casos limites e forçar o programa em seus limites máximos e mínimos de dados para ver seu comportamento. Esta técnica é conhecida como "valores limites": Dividimos os dados em classes, segundo o sentimento do programador que vai testar o programa. Uma classe para cada domínio de dado e, se o testador desconfiar que o programa se comporta de modo diferente em uma classe, divide-a em duas classes. Para cada classe de dados, testamos os valores limites do domínio: o maior valor, o menor valor, um valor fora do domínio imediatamente abaixo e imediatamente acima do domínio. Para cada classe de dados, sempre testamos um valor dentro da classe e um fora da classe. 4) Devemos ter uma atenção especial com tabelas (array's) e listas (ponteiros). Testar sempre o primeiro elemento, o último elemento, colocar um valor quando a tabela estiver vazia, colocar o último elemento e colocar um elemento a mais, para ver se o programa detecta. Para listas, testar para inserir o primeiro elemento, inserir antes do primeiro elemento, inserir depois do último, etc. O mesmo para a remoção: retirar o primeiro elemento, apagar o último, apagar um elemento que é único na lista, etc. 5) Teste "caixa branca": é quando examinamos o fonte do programa. Geralmente os teste caixa branca são muito mais eficientes que os caixa preta. A metodologia mais empregada é a conhecida como "revisões estruturadas" (walkthrought) em que um grupo de pares (pessoas no mesmo nível) se reúnem, organizadamente, com o objetivo de descobrir erros num programa (ou mesmo um outro produto

A maior ferramenta que um programador dispõe para fazer um programa certo é fazer um programa SIMPLES.qualquer. . O mecanismo das revisões estruturadas está bem descrito no livro "Revisões Estruturadas" de E. Esta é a meta de um bom programador. Yourdon. D .

Faça a estrutura do menu principal o mais parecido possível com a dos sistemas atuais. Acima disto já começa a criar dificuldades para o operador manipular submenus. ao contrário do que se pensa. O ideal deve ficar em até 2 a 3 subníveis de menu. A recomendação é que uma interface deve ser tão próxima quanto possível de outras interfaces que o usuário já esteja acostumado. Uma interface que faz com que o usuário se sinta bem ao mexer com o sistema e o sistema transmita a ele uma sensação de que é facil de ser operado. D . A essas qualidades chamamos de interface amigável. principalmente da área de comunicação visual. como o vermelho. Cores fortes. C . Isso é mais importante que o próprio desempenho do sistema. criam inúmeras dificuldades ao usuário em navegar ou clicar em um botao específico no programa ou consultar uma informação. Não dispense a implementação das teclas de acesso rápido. Interfaces muito cheias de animações e imagens. Esse tema é um ponto importante e tanto o analista como o programador não podem se descuidar dele. B . Labels e botões multicoloridos ou piscantes. Normalmente. Deve ter comandos intuitivos e visual caprichado. representar o propósito da janela em uso ou de uma operação específica nesta. com o nome da equipe que participou do projeto do sistema.II – DA INTERFACE AMIGÁVEL Com o desenvolvimento dos sistemas baseados em interfaces visuais.Evite usar menus em cascatas infinitas. Somente use-os com critério e para realmente chamar a atenção do usuário para um campo ou dado imprescindível. somente deverão ser usadas em locais que se pretende chamar a atenção do operador. há um padrão de interface a ser seguido por todos os aplicativos. em uma grande firma. fica cada vez mais importante uma aparência agradável e a facilidade de se lidar com as telas e comandos do sistema. Devem estar também limitadas a uma imagem por janela e sempre colocada em local distante da área de entrada ou saída de dados. A construção de uma interface amigável é muito trabalhosa e geralmente precisa de auxílio de outras especialidades. Ou então apenas conter o logotipo do sistema ou da empresa. Evite ao máximo usar Edits. além de transimitir uma impressão de que o mesmo é complexo e dificil de ser operado. Essa regra só deve ser quebrada em casos muito especiais. Algumas recomendações a serem seguidas: A . .Sempre coloque uma tela de créditos. Animações e imagens devem ser usadas restritamente e deverão.Não tire do usuário facilidades que o o sistema fornece. em caso de uso. A poluição visual é uma das maiores fontes de resistência dos usuários aos novos sistemas de computador e uma dos maiores causadores de erros de entrada de dados. devida a confusão visual que ele proporciona ao seu operador. Isso facilita o uso e dá uma identidade à firma. como redimensionamento e cores de tela. Uma interface amigável é um ponto decisivo no sucesso de um produto. Muitas vezes é o responsável pelo sucesso de um produto. Procure usar sempre as cores padrão do sistema operacional.

A maior ferramenta para a clareza de um programa é também a SIMPLICIDADE.A maior parte do dinheiro gasto na vida de um programa é para modificá-lo. Abaixo damos algumas dicas para a documentação de um bom programa: Para variáveis: 1) O nome da variável deve ter significativo ou seja deve dizer para que a variável é usada. Se houver necessidade. lb para label. 2) Não faça expressões grandes e complicadas. etc) seguido por um nome que represente a função do componente em sua aplicação. 2) Não tenha preguiça ao dar nome às variáveis. Para expressões aritméticas: 1) Use um branco cercando os operadores que aumenta a clareza. eb para editbox. 6) Não mapeie um tipo de variável em outro tipo.5) / 3) .III – DA CLAREZA A . O padrão Borland de dar nome aos componentes é o seguinte: duas letras minúsculas com o mnemônico do componente (por ex. divida em 2 ou mais atribuições. deve ao programar pensar no programador (muitas vezes ele próprio) que vai modifica-lo. mesmo que redundantes.2 / 3500 Neste caso a primeira operação a ser processada será a (B * 54. ab2). Bastará um parenteses esquecido . 8) Fuja de variáveis globais com o o diabo da cruz!!! Só use se não tiver outro jeito. 4) O uso de parênteses em expressões matemáticas é extremamente fundamental uma vez que é através deles que o compilador irá determinar a ordem de processamento das operações matemáticas.5) para em seguida será (A + ResuladoDaPrimeiraOperação / 3) para aí sim o restante da expresão. Um programador não deve pensar que seu programa é definitivo. 3) Evitar nomes parecidos (Ex: valor e valores. 4) Usar maiúsculas para aumentar a clareza de nomes compostos. mas cuidado com o excesso de parenteses. Por exemplo. Para constantes: 1) Definir constantes não inerentes ao algoritmo em sua seção expecífica. C . pode aumentar a clareza da expressão. 7) Troque sempre os nomes dos componentes. 3) O uso de parênteses. numItens e numeroItens) e nomes que não dizem nada (Ex: x1. B . nunca as duas. Sublinhado "_" também é uma boa opção para separar as palavras compostas. não use uma variável inteira para quardar um valor real. Use uma ou outra. 5) Não use uma variável para duas funções.A documentação também é uma arma importante que o bom programador recorre para aumentar a clareza. Ex: 5 x (A + (B * 54. bt para botões em geral.

o padrão proposto pelo fabricante da linguagem/ferramenta ou então o padrão proposto pelas entidades que regem estas regras (Ex: o SEI). O problema vai ser você achar este erro depois de um mês que o programa ficou pronto. O repeat/do while é mais intuitivo e mais fácil do programador iniciante entender. porém a condição de escape geralmente é feita na negativa (o que é ruim). Mas não ultrapasse três condições. use while ou repeat/do while. 3) Evite expressões na negativa. prefira um comando while ou repeat. use o repeat/do while. 4) Cuidado pois: not(A or B) = not A and not B e not(A and B) = not A or not B Para comandos if: 1) Evite aninhamentos grandes de if's. Recomendamos uma endentação de 3 espaços em cada bloco. Para comandos de repetição: 1) Como escolher entre o while. Às vezes é difícil fazer isso.ou colocado em outro lugar para o resultado da expressão já ser outro. Neste último caso. nem das variáveis envolvidas no cálculo do valor máximo do loop. 3) Não passe da coluna 80 (parte visível na tela). c) Se a condição de escape do loop é calculada dentro do loop. pois dificulta a leitura do programa. Expressões booleanas já são complicadas. b) No caso de termos saída de condição. A escolha entre um e outro comando. rode 10 vezes ou até achar um elemento. else if cond2 then etc. d) Se o loop puder ser executado zero vezes. Especialmente. É aceitável a construção: if cond1 then etc. por exemplo. Mesma coisa com try/except/finally e outros comandos com paravras chaves relacionadas. o repeat e o for: a) Se já sabe antes de começar o loop quantas vezes ele será executado. e) Entre o while e o repeat/do while: o while é mais geral. quando for indiferente. Para expressões lógicas: 1) Muito cuidado com as expressões lógicas pois são a fonte da maioria dos erros de um programa. não mude o valor da variável de controle. 2) Alinhe o íncio do bloco (chave de abertura ou begin} e o término do bloco (chave de fechamento ou end) ao comando correspondente. não use o for... Isto é muito importante. não complique mais. Use. Dê preferência ao for que é mais simples. preferencialmente e recomendadamente. 2) Use endentação para ressaltar o corpo do loop. Se necessário.. principalmente quando temos muitos blocos um . use o for. pode ser executado zero vezes. desdobre em dois if's ou duas ou mais expressões lógicas.. além de não dar para listar em papel comum. Endentação: 1) A finalidade da endentação é ressaltar a estrutura de um programa. não force a saída do comando atribuindo valor limite à variável de controle. use o while. fica por conta da preferência de cada programador. 3) Em um comando for. 2) Não faça expressões complicadas (com mais de dois operadores lógicos).

3) Quando for necessário fazer um trecho de algoritmo complicado. S: string. 2) Sempre coloque um comentário nas funções e procedimentos dizendo o que ela faz. tempo de execução ou espaço de memória. qual o significado dos parâmetros e domínio de validade dos parâmetros e argumentos.']) then S := S + Copy(Text. Se atenha ao que está no manual do fabricante. um cabeçalho no programa contendo (em sequencia): a) O nome da empresa b) O que o programa faz. 2) Evite macetes de programação para poupar comandos. I. ainda que ele seja "uma coisinha a toa" para ser implementada de última hora. Comentários: 1) Coloque sempre. begin S := ''. porém não comente demais e nem comente o óbvio.'9'. Isto facilita e deixa o código mais claro de ser lido e interpretado pelo programador. É uma boa norma de programação colocar trecho do algoritmo em alto nível antes do trecho de programa correspondente. d) Quais os componentes da equipe e seus respectivos emails. Se for necessário. 4) Não escreva o código no estilo Linha-abaixo-de-linha. 3) Evite qualquer tipo de improviso no codigo fonte do programa (Gambiarras). como comentário. Outras recomendações: 1) Não use características especiais de um comando. for I := 1 To Length(Text) Do if (Text[I] in ['0'. A solução é quebrar a linha para que caiba nas 80 colunas. 1). esta é a maior fonte de proliferação de bugs no programa. result := S. É muito importante que no programa fique claro a estrutura dos blocos. c) Data que o programa foi feito. ex: function RemoveCifrao(Const Text: string): String. Sem dúvida alguma. ..'. var I: integer. 4) Faça uso constante dos comentários.dentro do outro. end. Salte uma linha quando uma parte da rotina lógica encerrar e outra começar dentro de um mesmo procedimento ou função. comente o que foi feito. explique o que foi feito com comentários e o que o algoritmo faz.

desde que não seja óbvio. coloque essa expansão como comentário perto do trecho do programa correspondente. 7) Se uma parte do algoritmo precisar ser eliminada ou modificada. Neutralize a parte dispensável com comandos de comentario. não apague-a para reescrever de novo. pois caso você necessitar desta parte novamente.5) Se um trecho do algoritmo teve de ser expandido. . 6) Colocar como comentário o significado de uma variável ou constante junto com a definição da mesma. ela estará disponível.

Estudos feitos em vários programas com muito cálculo mostraram que cerca de 90% do tempo de execução é gasto em apenas 3% de código do programa. Esta parte é chamada loop mais interno (inner loop). B .Se o programa está lento por causa de entrada/saída. E .Se o programa demora por cálculos. F . .Geralmente um programa simples é eficiente. Não há a mínima necessidade deles serem criados no ato da execução do programa para ficarem no aguardo de serem usados em apenas um único módulo que é raramente acessado. Stringlists e Listas encadeadas) quando for realmente usá-los. Por exemplo: um programa leva 12 horas para dar a resposta e os computadores são desligados após o expediente.Só nos preocupamos com o tempo de execução quando for necessário. logo após seu uso. Somente o registro a ser mexido deve ser reservado ao programa. Tabelas somente deverão ser abertas quando forem usadas e.IV – DO TEMPO DE EXECUÇÃO A . nada mais faz a não ser propiciar a perda de dados devido a piques de energia ou falhas no sistema operacional. além de comprometer a performance do programa. Novamente voltamos à principal qualidade do programa que é ser SIMPLES E OBJETIVO. devemos identificar o loop mais interno do programa e melhorar somente esta parte do programa. e somente se for necessário. Qualquer melhoria feita fora desses 3% de código é inoperante. D . evite bloquear toda a tabela. C . será necessário redefinir os arquivos que usa.A melhoria de um programa é feita depois do programa estar pronto e certo.Se o programa for trabalhar em rede ou em modo compartilhado. Abrir tabelas no ato da execução do programa e somente fechá-las no encerramento deste. Em máquinas de grande porte há softwares especiais para identificar essas partes.Somente crie objetos (Forms. D . Complicações e implementações desnecessárias geralmente aumentam o tempo de execução. mas dá para identificar o inner loop apenas examinando o programa. É nesse pequeno trecho que nossa atenção deve ser concentrada. fechadas. para que os acessos sejam feitos de modo mais eficiente.

Procure aprender a usá-las pois elas são muito úteis na detecção de causadores de vazamento de memória. que foram requisitados pelo seu programa. O maior drama do programador é quando. porque. o computador fica lento e sem memória. após o programa ser finalizado.V – DA ECONOMIA DE MEMÓRIA A . Geralmente quanto menos variáveis um programa usar. . A WEB também está cheia de ferramentas Freeware e Shareware que auxiliam muito o programador em eliminar tais anomalias. para outra coisa ele não vai servir se não para consumir parte da memória.Novamente: a simplicidade conduz a programas menores e com menos variáveis. mais simples será e menos bytes de memória ele consumirá. QUE TABELAS QUE FORAM ABERTAS FORAM FECHADAS APÓS O USO. Se nosso programa não couber nesses 64k temos de dar um jeito para que caiba. temos o Winsight. costuma-se vir outras de depuração e monitoramento de memória. D . B . bloqueio indevido de tabelas ou de recursos de hardware que estão inascessíveis após serem usados pelo seu programa.Só nos preocupamos com a economia de memória quando for necessário. A preocupação deve então ser com a simplicidade e não com a economia de memória.Junto com a sua ferramenta de desenvolvimento. Atente também para recursos de hardware. No caso do Delphi. C .Certifique-se sempre de que TODO OBJETO QUE ESTÁ SENDO CRIADO NO SISTEMA ESTÁ SENDO DESTRUÍDO APÓS O SEU USO. Portanto jamais ignore as mensagens de aviso do compilador que variável X ou procedimento tal foi declarado mas nunca usado. e que deverão estar disponíveis para qualquer outro software após a sua finalização. fenômeno este conhecido como "vazamento de memória". o Turbo debugger e o SQL Monitor. Isto acontece quando o programa requisita uma determinada quantidade de memória para rodar e ao ser finalizado ele devolve menos do que pediu. Por exemplo: algumas versões antigas do Pascal tem um limite de 64k bytes para cada estrutura.

Sign up to vote on this title
UsefulNot useful