CARACTERSTICAS DE UM BOM PROGRAMA I DA CERTEZA A - Se um programa no estiver certo ele no cumpre as suas finalidades.

. B - Um programa certo, alm de fazer o que deve, tem que no fazer o que no deve. Por exemplo: Ao calcular a rea do tringulo de lados 4, 1, 1; o programa deve dizer que os lados no formam um tringulo e no dar um valor como resposta. Para isto, devemos sempre estabelecer o domnio de validade dos dados de Entrada do algoritmo e testar a validade da desses dados. C - No fcil fazer um programa certo, pois no h tcnica conhecida que garanta a exatido de um programa. Podemos mostrar que um programa est errado, mas no podemos mostrar que est 100% certo at que todos os testes possveis tiverem sido feitos. As consistncias, tanto de dados como do programa, devero estar restritas as necessidades dos mesmos. Excesso de consistncias e consistncias que consistem outras consistncias no agregam nada ao programa, fazem ele ficar mais lento e s serviro para proliferarem bugs e falhas no mesmo. Aps a elaborao do programa passamos fase de depurao, que quando tentamos descobrir erros no mesmo. Existem tcnicas para se testar um programa e abaixo damos algumas dicas: 1) Um programador nunca deve testar seu prprio programa, pois o teste uma tarefa destrutiva e o programador geralmente no gosta de destruir o que fez. Alm do mais ele j sabe perfeitamente como operar e como lanar os dados no programa o que impede que ele teste o comportamento do mesmo no caso de faltar lanar determinados dados ou lanar dados invlidos ou de outra forma. Isto pode omitir uma serie de possveis bugs que estejam ocultos ou que somente se manifestam em uma determinada situao. 2) Um teste de um programa tem sucesso quando se acha um erro. No tente mostrar que o programa est certo, pois isso, alm de ser uma tarefa impossvel, ir mascarar um problema que se manifestar futuramente comprometendo a credibilidade do sistema. 3) Teste "caixa preta": quando examinamos um programa por suas especificaes, sem olhar o cdigo. Ao realizar um teste, tentamos explorar os casos limites e forar o programa em seus limites mximos e mnimos de dados para ver seu comportamento. Esta tcnica conhecida como "valores limites": Dividimos os dados em classes, segundo o sentimento do programador que vai testar o programa. Uma classe para cada domnio 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 domnio: o maior valor, o menor valor, um valor fora do domnio imediatamente abaixo e imediatamente acima do domnio. Para cada classe de dados, sempre testamos um valor dentro da classe e um fora da classe. 4) Devemos ter uma ateno 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 remoo: 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 so muito mais eficientes que os caixa preta. A metodologia mais empregada a conhecida como "revises estruturadas" (walkthrought) em que um grupo de pares (pessoas no mesmo nvel) se renem, organizadamente, com o objetivo de descobrir erros num programa (ou mesmo um outro produto

qualquer. O mecanismo das revises estruturadas est bem descrito no livro "Revises Estruturadas" de E. Yourdon. D - A maior ferramenta que um programador dispe para fazer um programa certo fazer um programa SIMPLES. Esta a meta de um bom programador.

II DA INTERFACE AMIGVEL Com o desenvolvimento dos sistemas baseados em interfaces visuais, fica cada vez mais importante uma aparncia agradvel e a facilidade de se lidar com as telas e comandos do sistema. A essas qualidades chamamos de interface amigvel. Uma interface que faz com que o usurio se sinta bem ao mexer com o sistema e o sistema transmita a ele uma sensao de que facil de ser operado. Deve ter comandos intuitivos e visual caprichado. Uma interface amigvel um ponto decisivo no sucesso de um produto. Muitas vezes o responsvel pelo sucesso de um produto. Isso mais importante que o prprio desempenho do sistema. A recomendao que uma interface deve ser to prxima quanto possvel de outras interfaces que o usurio j esteja acostumado. Normalmente, em uma grande firma, h um padro de interface a ser seguido por todos os aplicativos. Isso facilita o uso e d uma identidade firma. A construo de uma interface amigvel muito trabalhosa e geralmente precisa de auxlio de outras especialidades, principalmente da rea de comunicao visual. Esse tema um ponto importante e tanto o analista como o programador no podem se descuidar dele. Interfaces muito cheias de animaes e imagens, ao contrrio do que se pensa, criam inmeras dificuldades ao usurio em navegar ou clicar em um botao especfico no programa ou consultar uma informao, alm de transimitir uma impresso de que o mesmo complexo e dificil de ser operado. A poluio visual uma das maiores fontes de resistncia dos usurios aos novos sistemas de computador e uma dos maiores causadores de erros de entrada de dados, devida a confuso visual que ele proporciona ao seu operador. Evite ao mximo usar Edits, Labels e botes multicoloridos ou piscantes. Somente use-os com critrio e para realmente chamar a ateno do usurio para um campo ou dado imprescindvel. Animaes e imagens devem ser usadas restritamente e devero, em caso de uso, representar o propsito da janela em uso ou de uma operao especfica nesta. Ou ento apenas conter o logotipo do sistema ou da empresa. Devem estar tambm limitadas a uma imagem por janela e sempre colocada em local distante da rea de entrada ou sada de dados. Procure usar sempre as cores padro do sistema operacional. Cores fortes, como o vermelho, somente devero ser usadas em locais que se pretende chamar a ateno do operador. Algumas recomendaes a serem seguidas: A - Sempre coloque uma tela de crditos, com o nome da equipe que participou do projeto do sistema. B - No tire do usurio facilidades que o o sistema fornece, como redimensionamento e cores de tela. Essa regra s deve ser quebrada em casos muito especiais. C - Faa a estrutura do menu principal o mais parecido possvel com a dos sistemas atuais. D - Evite usar menus em cascatas infinitas. O ideal deve ficar em at 2 a 3 subnveis de menu. Acima disto j comea a criar dificuldades para o operador manipular submenus. No dispense a implementao das teclas de acesso rpido.

III DA CLAREZA A - A maior parte do dinheiro gasto na vida de um programa para modific-lo. Um programador no deve pensar que seu programa definitivo, deve ao programar pensar no programador (muitas vezes ele prprio) que vai modifica-lo. B - A maior ferramenta para a clareza de um programa tambm a SIMPLICIDADE. C - A documentao tambm uma arma importante que o bom programador recorre para aumentar a clareza. Abaixo damos algumas dicas para a documentao de um bom programa: Para variveis: 1) O nome da varivel deve ter significativo ou seja deve dizer para que a varivel usada. 2) No tenha preguia ao dar nome s variveis. 3) Evitar nomes parecidos (Ex: valor e valores; numItens e numeroItens) e nomes que no dizem nada (Ex: x1, ab2). 4) Usar maisculas para aumentar a clareza de nomes compostos. Sublinhado "_" tambm uma boa opo para separar as palavras compostas. Use uma ou outra, nunca as duas. 5) No use uma varivel para duas funes. 6) No mapeie um tipo de varivel em outro tipo. Por exemplo, no use uma varivel inteira para quardar um valor real. 7) Troque sempre os nomes dos componentes. O padro Borland de dar nome aos componentes o seguinte: duas letras minsculas com o mnemnico do componente (por ex, lb para label, eb para editbox, bt para botes em geral, etc) seguido por um nome que represente a funo do componente em sua aplicao. 8) Fuja de variveis globais com o o diabo da cruz!!! S use se no tiver outro jeito. Para constantes: 1) Definir constantes no inerentes ao algoritmo em sua seo expecfica. Para expresses aritmticas: 1) Use um branco cercando os operadores que aumenta a clareza. 2) No faa expresses grandes e complicadas. Se houver necessidade, divida em 2 ou mais atribuies. 3) O uso de parnteses, mesmo que redundantes, pode aumentar a clareza da expresso, mas cuidado com o excesso de parenteses. 4) O uso de parnteses em expresses matemticas extremamente fundamental uma vez que atravs deles que o compilador ir determinar a ordem de processamento das operaes matemticas. Ex: 5 x (A + (B * 54,5) / 3) - 2 / 3500 Neste caso a primeira operao a ser processada ser a (B * 54,5) para em seguida ser (A + ResuladoDaPrimeiraOperao / 3) para a sim o restante da expreso. Bastar um parenteses esquecido

ou colocado em outro lugar para o resultado da expresso j ser outro. O problema vai ser voc achar este erro depois de um ms que o programa ficou pronto. Para expresses lgicas: 1) Muito cuidado com as expresses lgicas pois so a fonte da maioria dos erros de um programa. 2) No faa expresses complicadas (com mais de dois operadores lgicos). Expresses booleanas j so complicadas, no complique mais. Se necessrio, desdobre em dois if's ou duas ou mais expresses lgicas. 3) Evite expresses na negativa. 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. aceitvel a construo: if cond1 then etc... else if cond2 then etc... Mas no ultrapasse trs condies. Para comandos de repetio: 1) Como escolher entre o while, o repeat e o for: a) Se j sabe antes de comear o loop quantas vezes ele ser executado, use o for. D preferncia ao for que mais simples. b) No caso de termos sada de condio, por exemplo, rode 10 vezes ou at achar um elemento, no use o for, use while ou repeat/do while. c) Se a condio de escape do loop calculada dentro do loop, use o repeat/do while. d) Se o loop puder ser executado zero vezes, use o while. e) Entre o while e o repeat/do while: o while mais geral, pode ser executado zero vezes, porm a condio de escape geralmente feita na negativa (o que ruim). O repeat/do while mais intuitivo e mais fcil do programador iniciante entender. A escolha entre um e outro comando, quando for indiferente, fica por conta da preferncia de cada programador. 2) Use endentao para ressaltar o corpo do loop. 3) Em um comando for, no mude o valor da varivel de controle, nem das variveis envolvidas no clculo do valor mximo do loop. Especialmente, no force a sada do comando atribuindo valor limite varivel de controle. Neste ltimo caso, prefira um comando while ou repeat. Endentao: 1) A finalidade da endentao ressaltar a estrutura de um programa. Isto muito importante. Use, preferencialmente e recomendadamente, o padro proposto pelo fabricante da linguagem/ferramenta ou ento o padro proposto pelas entidades que regem estas regras (Ex: o SEI). Recomendamos uma endentao de 3 espaos em cada bloco. 2) Alinhe o ncio do bloco (chave de abertura ou begin} e o trmino do bloco (chave de fechamento ou end) ao comando correspondente. Mesma coisa com try/except/finally e outros comandos com paravras chaves relacionadas. 3) No passe da coluna 80 (parte visvel na tela), pois dificulta a leitura do programa, alm de no dar para listar em papel comum. s vezes difcil fazer isso, principalmente quando temos muitos blocos um

dentro do outro. A soluo quebrar a linha para que caiba nas 80 colunas. muito importante que no programa fique claro a estrutura dos blocos. 4) No escreva o cdigo no estilo Linha-abaixo-de-linha. Salte uma linha quando uma parte da rotina lgica encerrar e outra comear dentro de um mesmo procedimento ou funo, ex: function RemoveCifrao(Const Text: string): String; var I: integer; S: string; begin S := ''; for I := 1 To Length(Text) Do if (Text[I] in ['0'..'9',',']) then S := S + Copy(Text, I, 1); result := S; end; Isto facilita e deixa o cdigo mais claro de ser lido e interpretado pelo programador. Outras recomendaes: 1) No use caractersticas especiais de um comando. Se atenha ao que est no manual do fabricante. Se for necessrio, comente o que foi feito. 2) Evite macetes de programao para poupar comandos, tempo de execuo ou espao de memria. 3) Evite qualquer tipo de improviso no codigo fonte do programa (Gambiarras), ainda que ele seja "uma coisinha a toa" para ser implementada de ltima hora. Sem dvida alguma, esta a maior fonte de proliferao de bugs no programa. Comentrios: 1) Coloque sempre, como comentrio, um cabealho no programa contendo (em sequencia): a) O nome da empresa b) O que o programa faz. c) Data que o programa foi feito. d) Quais os componentes da equipe e seus respectivos emails. 2) Sempre coloque um comentrio nas funes e procedimentos dizendo o que ela faz, qual o significado dos parmetros e domnio de validade dos parmetros e argumentos. 3) Quando for necessrio fazer um trecho de algoritmo complicado, explique o que foi feito com comentrios e o que o algoritmo faz. 4) Faa uso constante dos comentrios, porm no comente demais e nem comente o bvio. uma boa norma de programao colocar trecho do algoritmo em alto nvel antes do trecho de programa correspondente.

5) Se um trecho do algoritmo teve de ser expandido, coloque essa expanso como comentrio perto do trecho do programa correspondente. 6) Colocar como comentrio o significado de uma varivel ou constante junto com a definio da mesma, desde que no seja bvio. 7) Se uma parte do algoritmo precisar ser eliminada ou modificada, no apague-a para reescrever de novo. Neutralize a parte dispensvel com comandos de comentario, pois caso voc necessitar desta parte novamente, ela estar disponvel.

IV DO TEMPO DE EXECUO A - S nos preocupamos com o tempo de execuo quando for necessrio. Por exemplo: um programa leva 12 horas para dar a resposta e os computadores so desligados aps o expediente. B - Geralmente um programa simples eficiente. Complicaes e implementaes desnecessrias geralmente aumentam o tempo de execuo. Novamente voltamos principal qualidade do programa que ser SIMPLES E OBJETIVO. C - A melhoria de um programa feita depois do programa estar pronto e certo, e somente se for necessrio. D - Se o programa est lento por causa de entrada/sada, ser necessrio redefinir os arquivos que usa, para que os acessos sejam feitos de modo mais eficiente. Abrir tabelas no ato da execuo do programa e somente fech-las no encerramento deste, nada mais faz a no ser propiciar a perda de dados devido a piques de energia ou falhas no sistema operacional, alm de comprometer a performance do programa. Tabelas somente devero ser abertas quando forem usadas e, logo aps seu uso, fechadas. D - Somente crie objetos (Forms, Stringlists e Listas encadeadas) quando for realmente us-los. No h a mnima necessidade deles serem criados no ato da execuo do programa para ficarem no aguardo de serem usados em apenas um nico mdulo que raramente acessado. F - Se o programa for trabalhar em rede ou em modo compartilhado, evite bloquear toda a tabela. Somente o registro a ser mexido deve ser reservado ao programa. E - Se o programa demora por clculos, devemos identificar o loop mais interno do programa e melhorar somente esta parte do programa. Estudos feitos em vrios programas com muito clculo mostraram que cerca de 90% do tempo de execuo gasto em apenas 3% de cdigo do programa. Esta parte chamada loop mais interno (inner loop). Em mquinas de grande porte h softwares especiais para identificar essas partes, mas d para identificar o inner loop apenas examinando o programa. Qualquer melhoria feita fora desses 3% de cdigo inoperante. nesse pequeno trecho que nossa ateno deve ser concentrada.

V DA ECONOMIA DE MEMRIA A - S nos preocupamos com a economia de memria quando for necessrio. Por exemplo: algumas verses antigas do Pascal tem um limite de 64k bytes para cada estrutura. Se nosso programa no couber nesses 64k temos de dar um jeito para que caiba. B - Novamente: a simplicidade conduz a programas menores e com menos variveis. Geralmente quanto menos variveis um programa usar, mais simples ser e menos bytes de memria ele consumir. A preocupao deve ento ser com a simplicidade e no com a economia de memria. Portanto jamais ignore as mensagens de aviso do compilador que varivel X ou procedimento tal foi declarado mas nunca usado, porque, para outra coisa ele no vai servir se no para consumir parte da memria. C - Certifique-se sempre de que TODO OBJETO QUE EST SENDO CRIADO NO SISTEMA EST SENDO DESTRUDO APS O SEU USO. QUE TABELAS QUE FORAM ABERTAS FORAM FECHADAS APS O USO. O maior drama do programador quando, aps o programa ser finalizado, o computador fica lento e sem memria, fenmeno este conhecido como "vazamento de memria". Isto acontece quando o programa requisita uma determinada quantidade de memria para rodar e ao ser finalizado ele devolve menos do que pediu. Atente tambm para recursos de hardware, que foram requisitados pelo seu programa, e que devero estar disponveis para qualquer outro software aps a sua finalizao. D - Junto com a sua ferramenta de desenvolvimento, costuma-se vir outras de depurao e monitoramento de memria. No caso do Delphi, temos o Winsight, o Turbo debugger e o SQL Monitor. Procure aprender a us-las pois elas so muito teis na deteco de causadores de vazamento de memria, bloqueio indevido de tabelas ou de recursos de hardware que esto inascessveis aps serem usados pelo seu programa. A WEB tambm est cheia de ferramentas Freeware e Shareware que auxiliam muito o programador em eliminar tais anomalias.