O Estilo Na Programação

Prévia do material em texto

O Estilo na programação
O trabalho de um programador consiste em conceber soluções de problemas e implementá-las como programas de computador. É importante que um programador iniciante reconheça a importância do estilo no exercício de sua profissão e desenvolva hábitos que o coloque em vantagem sobre outros programadores durante sua vida profissional. O estilo tem consequências diretas na programação; ele pode levar a um aumento da qualidade dos programas, e pode reduzir possíveis erros em tempo de execução, tornar o código partilhável e eficiente, isso apenas para começar.
"Quais são as características de um bom programa?", essa pergunta pode ter diferentes respostas baseada nos gostos pessoais e na experiência de quem responde. Mas há alguns conceitos que podem ser amplamente aceitos em comum.
O Programa funciona
Parece óbvio, mas não é. Esse ponto diz respeito ao objetivo principal do programa. Desvios de foco no desenvolvimento podem levar à não-solução ou solução parcial do problema original, e perca dos objetivos principais. Isso pode ser evitado, revisando continuamente as especificações e não incluindo, na implementação, características não requeridas especificamente (como códigos próprios, códigos por brincadeira, etc.). 
O Programa não tem erros
Os erros são inevitáveis, mas não podem ser corriqueiros. Devem ser previstos em tempo de desenvolvimento e evitados ao máximo, segundo a filosofia de Yourdan (1975). Muito se pesquisa sobre programas e rotinas que prevejam e ajudem a evitar erros, porém como isso ainda é caro e trabalhoso, ainda é responsabilidade do programados certificar-se de que os programas não tenham erros.
O Programa é bem documentado
É importante que um programa seja bem documentado, para que seja fácil a posterior manutenção ou modificação do programa, sendo benéfica ao próprio programador. A documentação pode se dividir em: a)documentação externa: que seria aquela menos técnica, mais voltada para dizer o que o programa faz, e como ele funciona. É uma importante descrição complementar do programa; b)Documentação interna, que são as codificações e os comentários no código, que detalham os procedimentos e norteiam o que está acontecendo no determinado trecho do código.
O programa é eficiente
O conceito de eficiência, antes, abrangia o aproveitamento do hardware, que era limitado. Hoje isso já não é mais problema, o conceito de eficiência seria mais amplo, voltado, inclusive, para o correto funcionamento e confiabilidade, a facilidade de manutenção e modificação. Um programa de dificil manutenção certamente é de baixa qualidade.
Fases do processo de programação
Qualquer consideração do próprio processo de programação deve ser iniciada pela separação das fases que o compõem. Um estudo (Cooke e Bunt[1975]) identifica as seguintes fases:
análise do Problema
Desenvolvimento da solução
Implementação da solução como um programa
Testes
Manutenção
A fase da Análise do problema: onde o programador estuda o problema antes de pensar em uma solução. Nessa fase é mais difícil a detecção de erros, que consomem muito tempo para serem corrigidos depois, no projeto.
Logo após vem o desenvolvimento da solução. Essa fase é predominantemente criativa, mas pode ser ser abordada de forma sistemática de modo a ser resolvida por um programador dedicado, porém pouco criativo. Quando um programador criativo, porém sem itinerário, inverte essa fase com a fase abaixo, há uma séria propensão a problemas futuros.
A terceira fase é a implementação da solução: transformar a fase 2 em código, em programa. Se a solução for bem definida, essa parte é altamente mecânica, dizendo respeito apenas à programação, sem envolver resoluções de problemas nem estudos de caso.
A quarta fase é a fase de teste do programa implementado. Segundo Dijkstra, os testes mostram a presença efetiva de erros e não a sua ausência; a única forma de mostrar que um programa está correto é testar todas as possibilidades (o teste exaustivo), algo impossível até para programas simples. Nesse caso, temos várias alternativas, como casos de testes preparados por terceiros ou pelo próprio usuário.
A última fase é a manutenção do programa. Segundo F. P. Brooks (1975), "o custo de manutenção de um programa de uso frequente é tipicamente 40% ou mais do custo de seu desenvolvimento. A manutenção consiste em atualizar o programa para determinados padrões, ou satisfazer novas necessidades do cliente. A manutenção é inevitável, mas deve ser minimizada a fim de não ocupar os programadores, para, em vez de criarem, fazerem manutenção.
A técnica "Top-Down"
A programação é uma atividade complexa, onde fatores diferentes se reúnem para a produção de uma rotina ou tarefa a ser executada. A melhor maneira de construir essa rotina é usando níveis de abstração, que como disse nIKLAUS wIRTH (1974), "é nossa mais importante ferramenta mental para lidar com a complexidade de um problema". Na abstração, resolvemos os problemas da maneira mais geral possível, e a partir daí, dividimos cada passo em outros passos menores, obtendo assim, um projeto detalhado do que é a resolução do tal problema, que pode ser transformado facilmente em algoritmo. Um exemplo seria o algoritmo "Tomar Café": Preparar o café; Colocar o café no copo; Beber. No passo "Preparar o café", detalhamos o processo: Colocar água no fogo; pegar o filtro de papel, colocar café,... Isso são níveis de abstração!
Elementos do estilo de programação
A importância de duas regras na produção de programas de boa qualidade foram enfatizadas neste capitulo . São elas: o manuseio da complexidade e a legibilidade. Sobre isso, Kernighan e Plauger (1976) escrevem:
O controle da complexidade é a essência da programação. Sempre seremos limitados pelo número de detalhes que poderemos manter, de uma só vez, em nossas cabeças. O que se tentou ensinar neste livro é como enfrentar a complexidade
Os programas são mais lidos do que escritos. Para corrigir erros ou modificar um programa, é necessário lê-lo e entendê-lo antes que a modificação possa ser feita. O controle da complexidade e a legibilidade são as chaves da compreensibidade. Se um programa não pode ser lido, não pode ser modificado e torna-se um programa de pouco valor.
No projeto do programa é onde podem ser obtidas as maiores vantagens na qualidade de um programa. Qualidade não é uma característica adicionável. Essa fase também é tida por muitos o local apropriado para encarar os problemas de erros. O ideal é nunca sacrificar clareza por eficiência, e nunca sacrificar clareza pela oportunidade de revelar sua inteligência.
Um projeto "Top-Down" pode dar a oportunidade de separação clara de funções, baseado na premissa de que a extensão de influência de qualquer decisão particular é razoavelmente pequena, e desta forma, seu impacto no próprio programa é tão localizado quanto possível.
Implementação de Programas
A implementação real de um programa é a fase mais interessante e mais importante do trabalho. Podemos tomar alguns cuidados com o código escrito, como por exemplo, gastar um pouco mais de tempo e simplificar estruturas de controle; dar nomes coerentes às variáveis para que essas façam sentido dentro do contexto, e, sempre declará-las para que o algoritmo esteja livre de prováveis erros por conta de variáveis que não contém corretamente os dados. Na apresentação do programa, a forma e a aparência da listagem do programa são essenciais à sua qualidade. Nessa subseção temos duas facetas do problema: comentários e divisão de parágrafos.
Sobre os comentários temos dois extremos: os que escrevem demais, e os que quase não escrevem. Os que não escrevem deixam seu código carente de informação, e o que escreve demais acaba poluindo o código, não cooperando em nada. Um bom meio termo seria um comentário de linha no início da função/subprograma, e em alguns casos em que a linguagem permita, um comentário ao fim de um comando específico, caso ele precise ser justificado. Atentar sempre para a modificação dos comentáriosconforme o código é modificado também, para que se mantenham coerentes.
Voltando ao código, a identação é de suma importância para um programa fácil de se entender, e que faça sentido. Uma parte do código sem identação pode comprometer alguns minutos do tempo do leitor até que ele consiga visualizar as estruturas, especialmente quando se trata de estruturas de decisão. Isso não gera erros, não compromete o sistema, mas tenha em mente que o código é um reflexo da sua organização diária!
A programação como uma atividade humana
Um programador de sucesso deve aprender a dominar uma grande variedade de diferentes habilidades, desde aquelas de natureza criativa, até as tarefas mecânicas, como a codificação. Programadores não são máquinas; eles têm limitações reais na capacidade de percepção e desempenho, e é imporetante que cada programador reconheça e aprenda a viver dentro de suas limitações básicas. Essas limitações humanas dividem-se em:
Efeitos do processamento de informação;
Efeitos Sociais;
Efeitos do Meio ambiente;
Efeitos de personalidade
Efeitos do processamento de informação
 resultam das limitações inerentes na confiabilidade de percepção, de memória e do conhecimento humano. O ser humano é um processador de informações imperfeito: simbolos são confundidos, detalhes de linguagem são esquecidos, entre outros. O que pode ser feito para reduzir essa fonte de erro? Minimizar os erros por percepção visual, mantendo o lay-out do código impecável, parágrafos adequados, facilitando movimento dos olhos, seriam bons começos. Manter o programa dentro da capacidade intelectual do programador traz bons benefícios nesse sentido também.
Efeitos Sociais
 A estrutura de um grupo de programação deve ser projetada para ajudar a superar o ego do programador, que na maioria das vezes, está competindo por melhores salários, ou por melhor desempenho do projeto. Weinberg introduziu a noção de programação sem ego, onde os programas não devem ser vistos como extensão do ego do criador, sendo passível de críticas e sugestões. Cada programador reconhece suas limitações e solicita pareceres sobre seu código. Nessa técnica, a incidência de erros é menor, o planejamento de projetos é menos afetado pela falta de um programador, e cada programador pode melhorar o seu programa lendo os programas de outros.
Efeitos do meio ambiente
O meio onde o programador trabalha (tanto físico quando em software) tem grande efeito na sua eficiência. A disponibilidade adequada de linguagens de programação e de sistemas de computador é um fator decisivo; uma boa biblioteca de programas e rotinas pode evitar a necessidade de se "reinventar a roda". O ambiente físico varia de pessoa para pessoa: alguns preferem silêncio absoluto, outros, preferem música de fundo. Muitos gostam de desenvolver códigos de madrugada, trabalhando até o começo da manhã. Cabe à empresa encontrar um ambiente que maximize a produtividade do pessoal de programação.
Algumas pessoas, apesar das melhores intençoes, não poderão ser programadores efetivos, devido às suas peculiaridades individuais de personalidade, como por exemplo negligência, falta de motivação, falta de organização, inabilidade para tomar ou dar direções ou inabilidade para trabalhar sob pressão. É dificil dizer o grau de impacto no indivíduo, mas programadores, analistas e gerentes devem estar cientes.
Concluímos nossa discussão observando que o reconhecimento é um grande passo para a solução. Cada programador deve reconhecer e administrar suas limitações. E a gerencia deve respeitar e reconhecer os efeitos do elemento humano no grupo de atividades.