[Tutorial] Técnicas de Programação

[[AM]Higor]

Fuçando em minhas coisas descobri um texto muito legal sobre técnicas em programação...

Sei que muitos aqui são experientes. Mas, para o iniciante é uma boa pedida.

Não me lembro quem é o autor ou onde arrumei. Só sei que foi um link da URFJ(equipe.ufrj.br)... Não sei ao certo...

COMPUTAÇÃO II

CARACTERÍSTICAS DE UM BOM PROGRAMA

(Em ordem de importância)

I - CERTO:

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á certo.

Após a elaboração do programa passamos à fase de depuração do programa, que é quando tentamos descobrir erros no mesmo. Existem técnicas para se testar um programa e abaixo damos algumas dicas:

1) Um programador não deve testar seu próprio programa, pois o teste é uma tarefa destrutiva e o programador geralmente não gosta de destruir o que fez.

2) Um teste de um programa tem sucesso quando acha um erro. Não tente mostrar que o programa está certo, pois isso é uma tarefa impossível.

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. 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.

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" (walkthroughts) 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 qualquer). O mecanismo das revisões estruturadas está bem descrito no livro "Revisões Estruturadas" de E. Yourdon.

D - A maior ferramenta que um programador dispõe para fazer um programa certo é fazer um programa SIMPLES. Esta é a meta de um bom programador.

II - INTERFACE AMIGÁVEL

Com o desenvolvimento dos sistemas baseados em interfaces visuais, como o Windows, fica cada vez mais importante uma aparência agradável e a facilidade de se lidar com as telas e comandos do sistema. A essas qualidades chamamos de interface amigável. Uma interface que faz com que o usuário se sinta bem ao mexer com o sistema. Deve ter comandos intuitivos e visual caprichado.

Uma interface amigável é um ponto decisivo no sucesso de um produto. Muitas vezes é o responsável pelo sucesso de um produto. O que você prefere, Netscape ou Explorer? Windows ou Linux? Para responder a esta pergunta certamente você levará em consideração a interface dos dois sistemas. Isso é mais importante que o próprio desempenho do sistema.

A recomendação que passo a vocês é que uma interface deve ser tão próxima quanto possível de outras interfaces que o usuário já esteja acostumado. Normalmente, em uma grande firma, há um padrão de interface a ser seguido por todos os aplicativos. Isso facilita o uso e dá uma identidade à firma. Como atualmente o Windows é um padrão universalmente aceito, recomendo que procurem, tanto quanto possível, seguir o "jeitão" dos programas Windows.

A construção de uma interface amigável é muito trabalhosa e geralmente precisa de auxílio de outras especialidades, principalmente da área de comunicação visual (design gráfico). Esse tema não faz parte desta disciplina, e nem é abordado com profundidade no curso, porém como é um ponto importante, o analista e programador não pode se descuidar dele.

Algumas recomendações a serem seguidas nessa disciplina:

A – Sempre coloque uma tela de créditos, com o nome do grupo e qual o trabalho.

B – Não tire do usuário facilidades que o Windows fornece, como redimensionamento e cores de tela. Essa regra só deve ser quebrada em casos muito especiais.

C – Faça a estrutura do menu principal o mais parecido possível com a do Windows. Por exemplo: Arquivo/Novo/Abrir/Fechar/.../Sair; Ajuda/.../Sobre; etc...

III - CLAREZA:

A - A maior parte do dinheiro gasto na vida de um programa é usado para modificá-lo. Um programador não deve pensar que seu programa é definitivo, deve ao programar pensar no programador (muitas vezes ele próprio) que vai modifica-lo.

B - A maior ferramenta para a clareza de um programa é também a SIMPLICIDADE.

C - A documentação também é uma arma importante que o bom programador recorre para aumentar a clareza. Abaixo damos algumas dicas para a documentação de um bom programa:

Para variáveis:

1) O nome da variável deve ser significativo ou seja deve dizer para que a variável é usada.

2) Não tenha preguiça ao dar nome às variáveis.

3) Evitar nomes parecidos (Ex: Valor e Valores; NumItens e NumeroItens) e nomes que não dizem nada (Ex: x1, ab2).

4) Usar maiúsculas para aumentar a clareza de nomes compostos. Sublinhado "_" também é uma boa opção para separar as palavras compostas.

5) Não use uma variável para duas funções.

6) Não mapeie um tipo de variável em outro tipo. Por exemplo, não use uma variável inteira para quardar um valor booleano ou um valor enumerado.

7) O nome de uma variável booleana não deve deixar dúvidas de seu valor true e false.

8) Troque sempre os nomes dos componentes. O padrão Borland de dar nome aos componentes é o seguinte: duas letras minúsculas com o mnemônico do componente (por ex, lb para label, eb para editbox, bt para botões em geral, etc) seguido por um nome que represente a função do componente em sua aplicação.

9) Fuja de variáveis globais com o o diabo da cruz!!! Só use se não tiver outro jeito.

Para constantes:

1) Definir constantes não inerentes ao algoritmo em const.

Para expressões aritméticas:

1) Use um branco cercando os operadores que aumenta a clareza.

2) Não faça expressões grandes e complicadas. Se houver necessidade, divida em 2 ou mais atribuições.

3) O uso de parênteses, mesmo que redundantes, pode aumentar a clareza da expressão.

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.

2) Não faça expressões complicadas (com mais de dois operadores lógicos and e or). Expressões booleanas já são complicadas, não complique mais. Se necessário, desdobre em dois if's ou duas ou mais expressões lógicas.

3) Evite expressões 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) Se possível evite aninhamentos grandes de if's. É aceitável a construção:

if cond1 then etc...

else if cond2 then etc...

else if cond3 then etc...

Para comandos de repetição:

1) Como escolher entre o while, o repeat e o for:

a) Se já sabe antes de começar o loop quantas vezes ele será executado, use o for. Dê preferência ao for que é mais simples.

b) No caso de termos saída de condição, por exemplo, rode 10 vezes ou até achar um elemento, não use o for, use while ou repeat.

c) Se a condição de escape do loop é calculada dentro do loop, use o repeat.

d) Se o loop puder ser executado zero vezes, use o while.

e) Entre o while e o repeat: o while é mais geral, pode ser executado zero vezes, porém a condição de escape geralmente é feita na negativa (o que é ruim). O repeat é mais intuitivo e mais fácil do programador iniciante entender. A escolha entre um e outro comando, quando for indiferente, fica por conta da preferência de cada programador.

2) Use indentação para ressaltar o corpo do loop.

3) Em um comando for, não mude o valor da variável de controle, nem das variáveis envolvidas no cálculo do valor máximo do loop. Especialmente, não force a saída do comando atribuindo valor limite à variável de controle. Neste último caso, prefira um comando while ou repeat.

Indentação:

1) A finalidade da indentação é ressaltar a estrutura de um programa. Isto é muito importante.

2) Alinhe o begin e o end, o repeat e o until, o then (ou o if) e o else correspondentes. Mesma coisa com try/except/finally e outros comandos com paravras chaves relacionadas.

3) Não passe da coluna 80 (parte visível na tela), pois dificulta a leitura do programa, além de não dar para listar em papel comum. Às vezes é difícil fazer isso, principalmente quando temos muitos blocos um dentro do outro (if's, begin's, repeat's, etc). A solução é quebrar a linha para que caiba nas 80 colunas. Com o tempo cada programador cria o seu estilo de indentação, porém é muito importante que no programa fique claro a estrutura dos blocos. A Borland recomenda uma indentação de 2 espaços em cada bloco.

Outras recomendações:

1) Não use características especiais de um comando. Se atenha ao que está no manual do fabricante. Se for necessário, comente o que foi feito.

2) Evite macetes de programação para poupar comandos, tempo de execução ou espaço de memória. Isso só deve ser feito em casos especiais que mostraremos mais adiante.

3) Seu programa não deve depender da representação interna de um valor na memória. Por exemplo, o número “2” será número “2” independente de como ele é armazenado na memória, se em binário, decimal ou qualquer outra forma. Você não deve usar a representeção interna de um número para controlar seu programa.

Comentários:

1) Coloque sempre, como comentário, um cabeçalho no programa contendo:

a) O que o programa faz.

b) Só para esta disciplina: qual o trabalho, quais os componentes do grupo e qual os emails dos componentes. Mais tarde bote apenas o nome do programador

c) Data que o programa foi feito.

d) Qual o domínio de validade dos dados para que o algoritmo funcione corretamente.

e) Algoritmo no nível mais alto, em português estruturado.

2) Sempre coloque um comentário nas procedures e functions dizendo o que ela faz, qual o significado dos parâmetros e domínio de validade dos algorítmos.

3) Quando for necessário fazer um trecho de programa complicado, explique o que foi feito com comentários.

4) Encha o programa de comentários, porém não comente o óbvio. É uma boa norma de programação colocar trecho do algoritmo em alto nível antes do trecho de programa correspondente.

5) Se um trecho do algoritmo teve de ser expandido, coloque essa expansão como comentário perto do trecho do programa correspondente.

6) Colocar como comentário o significado de uma variável junto com a definição da mesma, desde que não seja óbvio.

IV - TEMPO DE EXECUÇÃO:

A - NÃO É IMPORTANTE. Só nos preocupamos com o tempo de execução quando for necessário. Por exemplo: um programa leva 12 horas para dar a resposta e os micros devem são desligados após o expediente.

B - Geralmente um programa simples é eficiente. Complicações desnecessárias geralmente aumentam o tempo de execução. Novamente voltamos à principal qualidade do programa que é ser SIMPLES.

C - A melhoria de um programa é feita depois do programa estar pronto e certo, e somente se for necessário.

D - Se o programa está lento por causa de entrada/saída, será necessário redefinir os arquivos que usa, para que os acessos sejam feitos de modo mais eficiente. Isso é estudado em outras disciplinas (Banco de Dados e Estrutura de Dados II) e foge ao alcance desta disciplina.

E - Se o programa demora por cálculos, devemos identificar o loop mais interno do programa e melhorar somente esta parte do programa. 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). Em máquinas 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 código é inoperante. É nesse pequeno trecho que nossa atenção deve ser concentrada.

V - ECONOMIA DE MEMÓRIA:

A - NÃO É IMPORTANTE. Só nos preocupamos com a economia de memória quando for necessário.

B - Novamente: a simplicidade conduz a programas menores e com menos variáveis. Geralmente quanto menos variáveis um programa usar, mais simples será. A preocupação deve então ser com a simplicidade e não com a economia de memória.

[David Pintassilgo]

é pá! fizeste-me 'perder' aqui 10 minutos!!! 😛

Bom post, concordo com grande parte do que ai está.

[psiico]

A - Se um programa não estiver certo ele não cumpre as suas finalidades.

um bocado logico..mas sim senhora bom post 😛

[mogers]

Eu tb concordo com a maioria das coisas mas axo k "borraram a pintura" com estas frases:

IV - TEMPO DE EXECUÇÃO:

A - NÃO É IMPORTANTE. Só nos preocupamos com o tempo de execução quando for necessário.

V - ECONOMIA DE MEMÓRIA:

A - NÃO É IMPORTANTE. Só nos preocupamos com a economia de memória  quando for necessário.

Discordo totalmente destas afirmações. Por exemplo: a resolver um exercício das Olimpiadas Nacionais de Informática do ano passado: Num "pós-concurso" podiamos submeter os exercicios. Eu resolvi com cerca de 100 Bytes  de memória e o programa resolvia o exercício sempre instântaneamente. Um amigo meu usou mais de 20 MB de memória e também teve o exercício aceite embora o programa dele fosse 4 ou 5 vezes mais lento que o meu...

Será que estas questões não são importantes num programa "a sério" numa empresa? Eu penso que sim.

[psiico]

quanta maior velocidade e fluidez melhor,mais rapido as coisas sao processadas e o trabalho é despachado mais rapidamente!

[[AM]Higor]

Eu tb concordo com a maioria das coisas mas axo k "borraram a pintura" com estas frases:

IV - TEMPO DE EXECUÇÃO:

A - NÃO É IMPORTANTE. Só nos preocupamos com o tempo de execução quando for necessário.

V - ECONOMIA DE MEMÓRIA:

A - NÃO É IMPORTANTE. Só nos preocupamos com a economia de memória  quando for necessário.

Discordo totalmente destas afirmações. Por exemplo: a resolver um exercício das Olimpiadas Nacionais de Informática do ano passado: Num "pós-concurso" podiamos submeter os exercicios. Eu resolvi com cerca de 100 Bytes  de memória e o programa resolvia o exercício sempre instântaneamente. Um amigo meu usou mais de 20 MB de memória e também teve o exercício aceite embora o programa dele fosse 4 ou 5 vezes mais lento que o meu...

Será que estas questões não são importantes num programa "a sério" numa empresa? Eu penso que sim.

Mas no seu exemplo você  está dizendo uma situação em que é necessário se preocupar com o tempo de execução...

Mesma coisa a questão da memória... Acho que o autor esqueceu de colocar um "devemos" em algumas partes...

"A - NÃO É IMPORTANTE. Só devemos nos preocupamos com o tempo de execução quando for necessário."

"A - NÃO É IMPORTANTE. Só devemos nos  preocupamos com a economia de memória  quando for necessário."

[theproject]

Boas, o autor esqueceu-se de referir as duas coisas mais importantes para fazer software legível e com manutenção possível:

Abstraccao procedimental e de dados... sem isso eskecam toda a legibilidade e manutencao do código...

Quanto ao que o autor disse sobre a performance de tempo/espaco está correcto. Nao quero dizer que nao seja importante, claro que é, às vezes os requisitos de tempo/memória tornam uma solução particular completamente inútil ( ter um programa que demora 1s a calcular uma treta qq que tem de ser calculada em 1ms, nao interessa se dá a resposta certa ou nao... não é um programa aceitavel para o problema), mas o que o autor quer dizer é que a optimização só deve ser considerada DEPOIS de ter um algoritmo/programa correcto e antes da codificacao, ie na fase de modelacao de dados etc... Não se deve estar a programar a pensar como um algoritmo deve funcionar e estar ao mesmo tempo a pensar no que se pode optimizar... isso é a fonte de muitos bugs... Idealmente deve-se conceber uma solucao correcta e só depois ver o que se pode optimizar recorrendo eventualmente a profilers etc... O que o autor disse não é novidade, aliás existe uma frase muito conhecida para simbolizar isso:  "early optimization is the root of all evil" e é apenas isso que o autor quer focar, não que os programas/algoritmos não devam ser optimizados...

[EclipseX]

só a uma coisa que está a contradizer...

Um bom programador pensa em coisas simples

Um programa tem de ser fácil interface com o usuário

Logo, facilitar o interface complica o código a maior parte das vezes....

Concordo com o que foi dito, mas esta parte não é de todo "REAL"

[pedrosorio]

Higor' timestamp='1146159810' post='24648']

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á certo.

http://en.wikipedia.org/wiki/Formal_verification

[IceBrain]

4) Encha o programa de comentários, porém não comente o óbvio. É uma boa norma de programação colocar trecho do algoritmo em alto nível antes do trecho de programa correspondente.

Não concordo. Se o código é difícil de perceber por si, deve-se usar técnicas de refactoring (principalmente extrair métodos) para o tornar legível.

O código está sempre de acordo com a execução do programa, mas os comentários ao fim de duas ou três remodelações já estão desactualizados, e só vão prejudicar o trabalho.