Resumo da Unidade II do Livro Code Complete

Andr Luis Ribeiro, Gabriel Vincius Canzi Candido, Gustavo Augusto de Souza e Jackson Ricardo Guerino Jr. Instituto Federal do Paran, Cmpus Salgado Filho, Curitiba PR Brasil
{andreluis.cwb, gabiru.vinicius, jacksonguerinojr}@gmail.com, g.asouza@hotmail.com

Abstract. This article summarizes the Unit II - Creating High Quality Code of the book Code Complete by Steve McConnell, where the author describes some ways to improve your code, through the explanation of the software project. The purpose of this summary is to highlight the main points to be observed by developers when creating a code. Resumo. Este artigo resume a Unidade II Criando Cdigo de Alta Qualidade do livro Code Complete, de Steve McConnell, onde o autor descreve algumas maneiras de se melhorar o seu cdigo, atravs da explicao do projeto de software. O objetivo deste resumo destacar os principais pontos a serem observados por programadores na hora da criao de um cdigo.

1. Projeto de Software na Construo

Primeiro, projetos de software seriam uma inveno ou criao de um esquema para transformar uma especificao software operacional. Projetos de software um processo heurstico ou seja procedimentos a serem experimentados, que as vezes podem funcionar ou no. Nenhum projeto se adapta a todas as circunstancias, pode funcionar bem para um certo tipo de tarefa mas para outra tarefa no, mas os tcnicos tentam revisar o projeto para que ele se encaixe na determinada tarefa. 1.1. Importncia do controle da complexidade Frequentemente os projetos falham devidos a planejamentos mal feitos. Mas quando os projetos falham por motivos tcnicos, por causa de uma complexidade no controlada, ou seja, o software fica to complexo que ningum entende exatamente o que ele faz. Por isso importante o software ter complexidade mnima para que o projeto se torne mais fcil de se entender.

1.2. Nveis de projeto Existem cinco nveis de projetos: 01-Sistema de software: No nvel 1, onde projetado o sistema inteiro e onde a soluo pensada como um todo. 02-Diviso em subsistemas: Consiste na identificao de todos os subsistemas importantes, por exemplo: banco de dados,interface com o usurio, mecanismo de relatrio...entre outros. Dentro de cada subsistema , diferentes mtodos de projetos podem ser usados-escolhendo a melhor estratgia que se adapta. Dentro de um projeto cada subsistema pode interagir com outro subsistema. 03-Diviso em classes: Classe seria um elemento esttico no programa que pode receber atributos como idade,sexo,nome,etc. Neste nvel o projeto de software identifica todas as classes do sistema. A diviso de subsistemas em classes necessria em qualquer projeto, porque a diviso claramente distinta daquela do programa 04-Diviso em rotinas: Neste nvel, o projeto software inclui a diviso de cada classe em rotina. O ato de definir as rotinas da classe resulta em um melhor entendimento da interface da classe. 05- Projeto interno de rotina: Consiste e um rascunho das funcionalidades detalhadas das rotinas individualmente. O projeto consiste em atividades como a escrita de pseudocdigo, pesquisas de algoritmos, e como organizar os cdigos em uma rotina. Esse nvel sempre executado, embora as vezes inconscientemente. 1.3. Abstraes Um passo muito importante ao se criar um cdigo de alta qualidade criar uma boa interface. E, para isso, recomendvel o uso de abstrao. Abstrao a visualizao de uma operao complexa de uma forma simples. Uma interface de classe fornece uma abstrao da implementao que fica escondida por trs da interface. Na escolha entre duas abstraes semelhantes, tenha certeza de optar pela correta. Abstrao a capacidade de empregar um conceito enquanto se ignora seus detalhes. Sempre que se trabalha com o agregado, esta se trabalhando com abstraes.

Bons programadores utilizam a abstrao como uma garantia de uma programao mais rpida e segura. 1.4. Hierarquia a estrutura da informao disposta em camadas, que a representao mais geral esta contida no topo e a mais detalhada na parte de baixo. As hierarquias so uma ferramenta til para os software porque proporcionam que se tenha foco em apenas o nvel que se esta trabalhando no momento.

2. Classes Funcionais
2.1. Classes um conjunto de dados e rotinas que possuem uma responsabilidade coesa e bemdefinida. Saber isso necessrio para compreender os Tipos Abstratos de Dados (TADs), pois em muitos projetos voc usufruir das classes para obter um resultado satisfatrio (e uma exmia codificao). O entendimento dos TADs implicar numa maior facilidade para trabalhar com classes. Eles podem ser utilizados para manipular entidades reais. Trabalhe no domnio de um problema e no no domnio de programao de baixo nvel. Com os TADs possvel manipular mltiplas instncias de dados em ambientes no-orientados a objetos. Retornando o foco para as classes, podemos defini-las como um TAD, mais herana e polimorfismo. Lembre-se que cada classe deve implementar um, e somente um, TAD. Existem vrios motivos para se criar uma classe. Tenha um em mente que seja coerente, como modelar objetos abstratos, reduzir a complexidade, entre outros. Evite a criao de classes que estejam cientes de tudo e que tenham poder sobre tudo. Elimine classes que sejam irrelevantes e evite as que tenham verbos como nome. A definio de boas interfaces de classe conta muito na criao de um programa de alta qualidade. O projeto e a implementao internos da classe tambm so importantes. 2.2. Encapsulamento Encapsulamento um conceito mais forte que abstrao, pois ele impede que os detalhes sejam vistos, mesmo que voc queira. 2.3. Continncia Quando pensar em continncia, pense sempre em tem um. Continncia (ou agregao) a noo simples de que uma classe contm elementos de dados ou um objetivo primitivo. Pensar na expresso tem um facilita a compreenso deste termo.

2.4.

Herana

Quando pensar em herana, pense em um. Herana a ideia de que uma classe a especializao de outra. Seu objetivo a criao de um cdigo mais simplificado. Ela evita a necessidade de repetir cdigo e dados em vrios locais, centralizando-os dentro de uma classe de base. Herana mltipla? Essa ferramenta eficaz se consegue atingir seu objetivo com sucesso. Ento, recomenda-se evita-la para no danificar a codificao. De acordo com o autor, a herana mltipla til principalmente para definir mixins, classes simples usadas para adicionar um conjunto de propriedades em um objeto. Eles recebem esse nome por que permitem a mistura de propriedades nas classes derivadas. A herana tende a opor-se ao principal imperativo tcnico que voc tem como programador, que controlar a complexidade. Para este controle, voc deve manter uma forte tendncia contra a herana. 2.5. Construtores Um construtor determina que aes sero executadas na criao de objetos. Ele unicamente invocado no momento da criao do objeto. 2.6. Pacotes Um pacote uma estrutura nica de transmisso de dados ou uma sequncia de dados transmitida por uma rede ou linha de comunicao que utilize a comutao de pacotes. 2.7. Uma breve explicao Devemos ter em mente que as estratgias de classes variam de uma linguagem para outra: podemos ter classes redefinveis por padro ou no, ou ainda com algumas condies e peculiaridades. De qualquer maneira, as classes so um timo recurso a ser utilizado e com elas podemos aumentar significativamente o nvel de abstrao de nosso cdigo, a partir do uso de pacotes: agregao de grupos de objetos. Porm, mesmo que no haja suporte aos pacotes em nossa linguagem, possvel criar um conjunto de regras que definiriam padres e assim poderiam ser considerados, de alguma forma, como pacotes. Nestas regras, poderamos ter convenes quanto ao uso de nomes para classe e organizao de cdigo, de modo a facilitar a qual pacote tal classe pertence e regras para a utilizao dos pacotes entre si, se esta comunicao houver, e qual o seu tipo: herana ou continncia. Apesar de tudo, sempre devemos buscar cumprir o principal imperativo tcnico

do software e tentar ao mximo elevar o nvel de abstrao de nosso cdigo por intermdio das classes. 3. Rotinas de Alta Qualidade

Rotinas so procedimentos que so ativados para um nico propsito. Em C++ podem ser representadas pelas funes, que so criadas e chamadas ao longo de um programa sempre com o mesmo objetivo inicial. As rotinas, assim como as classes, so um poderoso e valioso recurso da programao, e podem ser usadas como uma forma de melhorar a legibilidade dos cdigos e torn-los mais eficientes do ponto de vista do desempenho, uma vez que no necessrio copiar aquele trecho de cdigo toda vez que quiser us-lo, bastando fazer uma chamada rotina criada. 3.1. Cuidados com rotinas A alta qualidade na criao e no uso de rotinas provm de um conjunto de hbitos que devemos criar e manter, incluindo: A atribuio de nomes que faam sentido e que indiquem o que tal funo faz ou retorna; Padronizao na disposio de cdigos; Dar somente um objetivo rotina, fazer com que ela realize somente uma operao necessria, e que no faa diversas alteraes e progressos em seu programa; Manter o segredo de informaes: quanto menos a rotina puder saber e alterar, menor ser a chance de erros e falhas; Alm de manter os cuidados bsicos com variveis e parmetros nas funes. Como muitas outras ferramentas da programao orientada a objetos, se usadas da maneira correta, as rotinas podem ajudar a reduzir a complexidade, criar abstraes, evitar cdigo duplicado, ocultar operaes que o resto do programa no precisa ter conhecimento, aumentar a legibilidade, compreenso e facilidade de manuteno de cdigo, j que as alteraes feitas nas rotinas no alteram o resto do programa. 3.2. Coeso, nomes de rotinas e parmetros Como discutido anteriormente, o projeto de software possui um nvel dedicado s rotinas, logo devemos tirar proveito disto e nesta fase devemos procurar manter a coeso das rotinas. Coeso o termo usado para se referir intimidade das operaes de determinada rotina. Por exemplo, uma funo cos() que calcula o cosseno de um

ngulo, completamente coesa, j que ela faz somente uma operao. Por outro lado, uma rotina cosEtan() j no to coesa, pois a mesma rotina calcula dois valores diferentes e que no esto ligados entre si. O objetivo da coeso em rotinas fazer com que cada uma delas faa uma, e somente uma atividade, porm bem feita. Existem discusses acerca deste assunto e h vrios tipos de coeso, envolvendo a sequncia com que as operaes devem ser executados ou com o tipo de dados que uma rotina usa, porm o tipo mais comum e importante de coeso a coeso funcional, quando a rotina executa somente uma operao, que o caso de rotinas como CalculaIdade(), ApagarArquivo(), sen(), entre outras, desde que tais rotinas faam o que est descrito em seus nomes, caso contrrio no sero mais coesas. Apesar de parecer complicado de incio, os nomes das rotinas so muito importantes, pois a facilidade que elas lhe proporcionaro ao ler seu cdigo s depende de seu nome, que deve, basicamente, conter exatamente o que a funo faz, por mais longo que necessite ser, indicando o que a rotina retorna ou o que ela faz(imprime um texto na tela ou algo do gnero);alm disso, outro fator importante no separar a rotina em partes para ela no ficar muito longa: as vezes, realmente necessrio que uma rotina seja extensa, o que faz ela ter em torno de 50 a 150 linhas. importante haver uma organizao na declarao dos parmetros da rotina, que se forem declarados em uma ordem de entrada/modificao/sada, facilitaro o entendimento do seu cdigo. Outra prtica bastante til criar convenes para estes tipos de parmetros, com prefixos exclusivos para entrada, modificao e sada. 3.3. Cuidados com os parmetros das rotinas Caso vrias rotinas usem parmetros semelhantes, crie um padro que indique somente tal parmetro e o ajude a lembrar deste detalhe, como as rotinas em C strcpy() e memcpy(), que recebem os argumentos de destino, de origem e nmero mximo de bytes, na mesma ordem. Tal semelhana ajuda no entendimento do cdigo e dos parmetros destas rotinas. A partir do momento que um parmetro passado, ele deve ser usado em algum lugar da sua rotina, se no o fizer, alm de perder tempo e desempenho armazenando algo que no vai ser usado, voc pode ser induzido ao erro devido ao excesso de informaes juntas. Procure tambm limitar o nmero de parmetros (em sete o recomendado), mantendo o acoplamento de suas rotinas baico. Obedecendo ainda ao padro entrada/modificao/sada descrito acima, os parmetros de erro e status devem vir por ltimo. Parmetros no devem ser usados para armazenar clculos e operaes intermedirias dentro da rotina, para isso, crie uma varivel local, desta maneira, voc estar preservando o valor passado como parmetro

e se posteriormente precisar usar este valor original, ele estar disponvel em qualquer rea da rotina. A documentao se torna essencial neste ponto para descrever cdigos de status e erros(apesar de ser recomendado o uso de enumeradores para isso), determinar as unidades com as quais ir trabalhar, valores esperados e valores que no podem aparecer nos parmetros da rotina. Tal prtica torna muito mais fcil o entendimento e a manuteno do cdigo. 4. Programao Defensiva

Na programao, necessrio tomar alguns cuidados, se proteger dos dados invlidos, ou lixos, que entram no seu programa e ter uma maneira de desviar deles, ou gerar uma resposta elegante a este tipo de dado. Para obter xito neste aspecto, quando seu programa receber um valor de uma fonte externa, como o usurio, verifique se este valor est dentro dos intervalos esperados(quando inteiro) ou tem um tamanho adequado(quando strings). Caso no esteja de acordo com o esperado, rejeite o valor. Faa o mesmo com os parmetros de entrada das rotinas, pois so idnticos ao fato anterior, exceto por virem de uma outra rotina. Por fim, decida o que ir fazer com os valores invlidos. 4.1. Assertativas O uso de assertativas pode ser uma boa opo na verificao de valores. Assertativas so cdigos que verificam se algo est dentro dos padres: se tudo estiver certo nada ocorrer, porm se a assertativa for falsa isto indica que os limites foram ultrapassados e isto ser indicado a voc por meio de uma mensagem. Os prprios programadores podem criar seus mecanismos de assertativas com rotinas de macro ou funes. Este mecanismo porm, s deve ser usado para verificar condies que nunca deveriam ocorrer. Caso voc j espere algum tipo de erro, deve-se usar cdigos de tratamento de erros, e no assertativas. Um bom uso das assertativas a verificao e documentao de pr-condies e ps-condies, na qual as assertativas substituem os comentrios e ainda podem verificar dinamicamente a validade destas condies. 4.2. Exceo s assertativas Quando os erros que ocorrem so esperados por voc, programador, eles devem ser tratados de uma maneira diferente, e h diversas formas de faz-lo:

Retornar um valor neutro(zero ou string nula); Substituir pelos prximos valores vlidos(em um fluxo de dados, quando h uma entrada invlida, pode ser feita uma nova verificao logo em seguida e se os novos dados forem vlidos, eles substituem os invlidos anteriores); Retornar a mesma resposta da vez anterior; Substituir pelo valor vlido mais prximo; Registrar uma mensagem de alerta em um arquivo de log, relatando o problema; Retornar um cdigo de erro; Chamar uma rotina exclusiva de tratamento de erro; Exibir uma mensagem de erro quando o erro for encontrado; Terminar a execuo do programa. 4.3. Robustez versus correo Robustez significa sempre tentar que o software continue funcionando. Correo Significa nunca retornar um resultado impreciso, antes no retornar nada. No caso de que segurana extremamente necessria tem que priorizar a correo, diminuindo o foco da robustez. melhor no haver retorno do que um retorno errado. Em casos comerciais, deve-se priorizar a robustez. Pois qualquer resultado melhor que um encerramento do software. 4.4. Implicaes do processamento de erro no projeto de alto nvel O tratamento dos erros determina a qualidade do atendimentos dos requisitos necessitados. Em algumas linguagens os erros podem ser ignorados, porm recomendado que no ignore os erros. O principal objetivo da programao defensiva se precaver dos erros que voc no espera 4.5. Excees Excees so um meio especfico pelo qual o cdigo pode passar erros ou eventos excepcionais ao cdigo que o chamou. As excees so necessrias para que o cdigo esteja sempre documentando eventuais erros, e nunca deixar descoberta partes fundamentais do cdigo e preferencialmente s essas partes, e as trate localmente. Devem ser tomadas em determinado nvel de

abstrao, dependendo de sua funo. Em sua notificao devem ser colocados todos os dados, que a leva. No deixe blocos catch vazios, pois no mostra qual motivo que entrou nesse bloco. Todas as excees, preferencialmente, devem estar padronizadas para melhor controle dessas excees. Sempre pense em fazer alternativas as excees como, por exemplo, criar um arquivo de log. E o mais importante s crie excees se for necessrio. 4.6. Barricadas Crie sempre uma diviso de cdigos para defender os cdigos principais com uma espcie de firewall se certa parte do cdigo for afetado no obstrua as partes principais. E sempre converta dados externos (comummente, inteiros e strings) em seu valor que ser utilizado. 4.7. Auxiliares de Depurao

Sempre que possvel e j formao do cdigo crie auxiliares de depurao para seu projeto para que possa agilmente perceber o erro e j o diagnosticar. Programao ofensiva

Torne o problema incomodo o para que seja resolvido mais rpido. Preencha toda a memria alocada, para que nela sejam detectados os erros. Faa que os blocos default falhem ou seja impossvel desprezar. Faa que o programa envie um log para voc, para que fique sabendo que erros seu software est sofrendo

s vezes a melhor defesa um bom ataque

Quando o software for para fins comerciais, remova os auxiliares de depurao e use ferramentas de controle de verso como o ant e o make. E se a linguagem de programao disponibilizar use pr-processadores internos como, por exemplo, #if defined <debug> [C++], e se a linguagem de programao no possuir prprocessadores crie o seu prprio. Se necessrio utilize stubs de depurao, que so rotinas que apenas retorna o controle imediatamente para o que fez a chamada ou que executa algumas operaes rpidas antes de retornar o controle. Quando deve ser excludos o cdigo de programao ofensiva ou mantidos: Mantenha o cdigo que informa os erros mais importantes e os que identificam os simples devem der retirados, e tambm os que desencadeiam falhas srias. Mantenha o

cdigo que faz com que o software encerre harmoniosamente.

5. O Processo de Programao com Pseudocdigo (PPP)

Para criar um cdigo de qualidade, devem se criar as rotinas no interior de classes e examina-las. O termo pseudocdigo, apresenta seu significado como: notao informal em sua lngua natural. Dentre esse tipo de programao recomendado que no traduza o cdigo, e escrever em nvel suficientemente baixo, para diminuir os riscos de atenuar pequenos erros. Para criar um pseudocdigo necessrio: cria-se o projeto, codifica-o , verificao, limpa dele o que sobrou e se necessrio repita o processo. Verifique os pr requisitos e crie a rotina. Para que seja criado uma boa rotina deve ser dado um nome que a identifique, decida como vai test-la, procure usar sempre as bibliotecas padres, e se no tiver procure em livros, e por ultimo pense no tratamento dos erros. Depois de seguir os passos supracitados escreva o pseudocdigo que ser pouco se seguiu corretamente os passos anteriores. Aps todos esses passos, se necessrio, transforme esse cdigo em uma linguagem de alto nvel, com bons comentrios. Verificar um dos passos principais para construo de cdigo, o primeiro passo mental e logo aps compile, e depure (vulgo Debug) para ver se executa conforme o esperado, teste-o e remova os erros. Existem, pois, mais alternativas para a criao de rotinas e classes, como: Test-first: Testar primeiro ou testar por ltimo; Refatorao: Melhoria do cdigo com transformaes sem alterar a semntica; Entre outros.

Referncias
McConnell, Steve. (2005) Code Complete: Um guia prtico para a construo de software. http://www.dca.fee.unicamp.br/cursos/PooJava/metodos/construtor.html http://pt.wikipedia.org/wiki/Pacote