No comente seu cdigoVoc usa desodorante nas axilas? Se usa, provavelmente o faz por causa do mau cheiro produzido pelas suas glndulas sudorparas dessa regio. por um motivo semelhante que muitos programadores escrevem comentrios. Seu cdigo difcil de compreender, por isso precisa ser comentado. Mas se o cdigo ruim fosse refatorado at se tornar um bom cdigo, a maioria dos comentrios seriam desnecessrios.1 - Comentrios como desodoranteCom a ajuda doMartin Fowlerno seulivro sobre refatorao, me dei conta de que muitos dos comentrios que eu escrevia no passado eram usados para minimizar os efeitos de um cdigo ruim (do ponto de vista da clareza, no da eficincia). O cdigo ruim, segundo Fowler, cheira mal e os comentrios, neste caso, agem como desodorante. A seguir, alguns desses maus usos de comentrios.1.1 - Para compensar a m nomeao de identificadoresSe voc sentir a necessidade de comentar pra que serve uma vrivel, constante, funo, parmetro de funo, atributo, classe ou mtodo*, provavelmente o nome que voc deu ao identificador no um bom nome.Sem ser dogmtico, sugiro o seguinte:'Quando voc sentir a necessidade de escrever um comentrio para explicar o que faz ou pra que serve determinado identificador, transforme o comentrio que voc escreveria no nome do identificador.' (uma adaptao de algumas frases do Fowler)Transformar um comentrio curto em um nome de varivel fcil (a menos que voc use uma varivel para vrias coisas diferentes). Mas, transformar um comentrio de vrias linhas em um nome de funo dar mais trabalho, porm, neste caso, os comentrios longos so consequncia de um outro problema: funes longas.1.2 - Para compensar a escrita de funes longasQuem escreve uma funo com muitas linhas, normalmente sente a necessidade de adicionar um comentrio junto declarao da funo para explicar as coisas que ela faz. No corpo de funes desse tipo, tambm comum encontrar comentrios para explicar certos agrupamentos de cdigo. Em ambos os casos, os comentrios so um indcio de que o cdigo no est suficientemente claro.Ao invs de se eximir da responsabilidade pelo mau cdigo atrs de comentrios, refatore o cdigo desmembrando a funo longa em vrias funes menores. Se h comentrios ao longo do corpo da funo, esses comentrios do uma dica do que pode ser extrado e do nome que voc pode dar a cada funo extrada.Laos com muitas linhas de cdigo dentro de uma funo so terrveis para compreender, especialmente laos aninhados. Se voc reduzir o nmero de linhas dentro de um lao de forma que possa observar sem usar scroll onde comea e onde termina o lao, seu cdigo ser mais fcil de compreender.1.3 - Para explicar o uso de strings e nmeros literaisStrings e nmeros literais so valores escritos diretamente no cdigo. Por exemplo, em certo programa, pode ser convencionado que os tipos de inscrio CPF e CNPJ sero representados pelos inteiros 1 e 2, respectivamente. Se o programador decidir usar os literais 1 e 2 em todo cdigo que lide com os tipos de inscrio, ele provavelmente compensar isso com o uso de comentrios. Exemplo (em Java):/* Exemplo A */String getInscricaoFormatada1(int tipoInscricao, String inscricao) {

if (tipoInscricao==1) /* 1=CPF */ return formatarTexto("999.999.999-99", inscricao); else if (tipoInscricao==2) /* 2=CNPJ */ return formatarTexto("99.999.999/9999-99", inscricao); else return inscricao;}Apesar de o cdigo acima permitir uma fcil compreenso, o prximo cdigo - que no usa comentrios - tende a ser mais adequado./* Exemplo B */static final int TIPO_INSCRICAO_CPF = 1;static final int TIPO_INSCRICAO_CNPJ = 2;

String getInscricaoFormatada2(int tipoInscricao, String inscricao) {

if (tipoInscricao == TIPO_INSCRICAO_CPF) return formatarTexto("999.999.999-99", inscricao); else if (tipoInscricao == TIPO_INSCRICAO_CNPJ) return formatarTexto("99.999.999/9999-99", inscricao); else return inscricao;}A alternativa "B" prefervel porque, alm de dispensar o uso de comentrios, evita erros. Se voc digitar incorretamente o nome de uma constante ao fazer uso dela, o compilador perceber, enquanto ele no poder ajudar se voc fizer uso de um literal incorreto.3 - Quando usar comentrios?Tudo bem se voc achar que estou sendo contraditrio neste tpico por causa do ttulo que escolhi para o artigo. A verdade que eu gosto dos comentrios, desde que no sejam usados como desodorante. Aqui vo alguns dos usos que considero adequados.3.1 - Para organizar o pensamento sobre o cdigoQuando no uso um quadro ou papel para rascunhar o que vou codificar, uso comentrios para criar uma lista de passos que preciso seguir para atingir o objetivo do cdigo. Esses passos no precisam ser precisos, apenas precisam ser "persistidos" em algum lugar para que eu no esquea deles. medida que os passos so concludos, removo os comentrios, pois nesse ponto se tornam irrelevantes.3.2 - Para marcar cdigo duvidoso, passvel de melhora ou incompletoH casos em que algumas suposies precisam ser temporariamente assumidas como verdadeiras para que a codificao flua sem empecilhos. Nestes casos, til marcar o cdigo duvidoso com um comentrio precedido por um "TODO" ("fazer", em ingls). O mesmo se d com cdigos passveis de melhora ou incompletos. Alguns exemplos: /* TODO: confirmar se o DV da conta calculado com mdulo 10 */ /* TODO: refatorar este cdigo para remover as duplicaes /* /* TODO: validar campos obrigatrios antes de gravar /*PS: IDE's de desenvolvimento modernas permitem a fcil localizao dos comentrios marcados com "TODO".3.3 - Para explicarporquevoc fez algoH certas ocasies em que voc precisa explicarporquefez algo no cdigo - especialmente quando isso torna o cdigo mais complexo. Quando no bvio o porqu de uma deciso e voc no esclarece isso com comentrios, h o risco de que algum programador, ao assumir o seu trabalho, torne o cdigo mais simples - o que pode levar a falhas que ele no tem condies de prever ou a um mau desempenho.Um bom exemplo um comentrio escrito por nada menos queLinus Torvaldsnumarquivo fontedoGit(em C) para justificar a criao de um alocador de memria especializado ao invs de utilizar a funo malloc() padro: /* * alloc.c - specialized allocator for internal objects * * Copyright (C) 2006 Linus Torvalds * * The standard malloc/free wastes too much space for objects, partly * because it maintains all the allocation infrastructure (which isn't * needed, since we never free an object descriptor anyway), but even * more because it ends up with maximal alignment because it doesn't * know what the object alignment for the new allocation is. */ConclusoPara encerrar, duas timas citaes:"Qualquer tolo consegue escrever cdigo que um computador entenda. Bons programadores escrevem cdigo que humanos possam entender." (Martin Fowler)"Sempre codifique como se o programador que vai dar manuteno no seu cdigo fosse um serial killer manaco que sabe onde voc mora." (autor desconhecido)Gostou do que leu? Deixe seu/*comentrio*/.*^A rigor, varivel e atributo so coisas diferentes, assim como funo e mtodo. Mas, para fins de simplificao, quando eu disser "varivel", estarei me referindo tambm a "atributo" e quando disser "funo" estarei me referindo tambm a mtodo.Crdito da foto: George MarksReferncias: Martin Fowler."Refatorao: aperfeioando o projeto de cdigo existente" Jeff Vogel."Six ways to write more comprehensible code"

Tcnicas para um cdigo limpo 1. Boas PrticasClean CodeTcnica para um cdigo limpoRodrigo KonoMVP, MCTS, MCPD, MCT, MCP@rodrigokonowww.rodrigokono.net 2.Rodrigo Kono MVP Microsoft MCP MCTS MCPD MCT Foco em desenvolvimento WEB Developer na LG Sistemas Fundador do DevGois.NET Dez anos de comunidade .NET Palestrou em mais de 12 capitais Mais de 14.500 pessoas nesse tempo Finalista Imagine Cup 2005 Brasil/Japo 3.E ao meu lado hoje...Frederico Maia Arantes 5 anos de experincia em Desenvolvimento de Software. 3 anos de experincia em Desenvolvimento Java. 2 anos de experincia como instrutor de treinamentos. Membro e coordenador do Grupo de Usurios Java de Gois (Gojava).. 4.H duas razes pelas quaisvoc est nesta palestra:1. Voc um programador2. Deseja se tornar um ainda melhor. 5.TIMO! PRECISAMOS DE PROGRAMADORES MELHORES C. Martin Robert 6.The Clean CoderRobert C. Martin (Uncle Bob); Programador desde 1970;Fundador e Presidente Object Mentor Inc.Livros:Designing Object-Oriented C++ Applications using the Booch Method. 1995.Agile Software Development: Principles, Patterns and Practices. 2002.Clean Code: A Handbook of Agile Software Craftsmanship. 7.O que Clean Code? 8. Eficiente Simples Direto ao ponto Mnimas dependncias Sem duplicao Fcil manuteno Padres definidos Fcil leitura e entendimento Coberto de testes Elegante Sndrome da janela quebrada 9.Que porta representa o seu cdigo? 10."Qualquer um consegue escrever cdigo que um computador entende. Bons programadores escrevem cdigo que humanos endentem Martin Fowler 11.Funcionar o mnimo que se espera 12.Ah! Mas o cronograma apertado.No tenho tempo parafrescura!Meu chefe est mepressionando!Quero mostrarprodutividade. 13.Filho feio no tem pai! 14.Afinal, de quem a culpa? 15. nossa! 16.Como mensurar aqualidade de um cdigo? 17.OK! Vamos ao que interessa 18.NOMESSIGNIFICATIVOS 19.Nomes significativos int d; // tempo transcorrido em dias int tempoTranscorridoEmDias; int diasDesdeCriacaoDoArquivo; int diasDesdeModificacaoDoArquivo; int idadeDoArquivoEmDias; 20.Use nomes que revelem a inteno 21.Nomes significativos public List obter() public List obtemDiasMarcados() { { int[] x = new int[3]; int[] diaMarcado = new int[3]; List lista1 = new List(); List diasMarcados = new List(); for (int i = 0; i < lista; i++) for (int dia = 0; dia < mes; dia++) { { if (x[0] == 4) if (diaMarcado[STATUS] == MARCADO) { { lista1.Add(x[0]); diasMarcados.Add(diaMarcado[STATUS]); } } } } return lista1; return diasMarcados; } } 22.Nomes significativos public List obtemDiasMarcados() { int[] diaMarcado = new int[3]; List diasMarcados = new List(); foreach (Dia dia in mes) { if (dia.marcado) { diasMarcados.Add(dia); } } return diasMarcados; } 23.Use nomespronunciveis 24.Nomes significativos class DtaRcrd102 { private DateTime gerdmahms; private DateTime moddmahms; private string pszqint = "102"; } class Cliente { private DateTime gerarDataHora; private DateTime modificarDataHora; private string idRegistro = "102"; } 25.Use nomes buscveis 26.Nomes significativos for (int j = 0; j < 30; j++) { s = (t[j]*4)/5; } const int DIAS_DE_TRABALHO_POR_SEMANA = 5; int soma = 0; int diasReaisDeTrabalho = 4; for (int j = 0; j < NUMERO_DE_TAREFAS; j++) { int tarefasPorDia = trabalhoEstimado[j] * diasReaisDetrabalho; int taredasPorSemana = (dias / DIAS_DE_TRABALHO_POR_SEMANA); soma += taredasPorSemana; } 27.Nomeando classes e mtodos 28.Nomes significativosClasses representadas por substantivos ex: Cliente, Perfil, Estoque, etcMtodos representadas por verbos ou frasesverbais ex: enviarPagamento, salvar, etc. 29.FUNES 30.Seja pequeno 31.Funes Menos mais! Extraia trechos em mtodos privados. Lembre-se dos nomes significativos V direto ao ponto. 32.Funes 33.Faa uma coisa s! 34.Funes Repare a endentao (sim, assim que escreve) Muitos nveis ~= muita responsabilidade O mtodo deve fazer uma nica coisa, e bem! Est fazendo mais de uma coisa? Extraia. 35.Leia o cdigo de cima pra baixo 36.Funes Seu cdigo deve ser lido como uma narrativa Temos sujeitos, verbos e predicados Narrativas so frases em ordem coerente Lembre-se disto ao extrair em mtodos privados; 37.Funes Muitos argumentos = code smell Existem algumas regras para a quantidade de argumentos Argumentos booleanos, em geral, no so bons. 38.Funes 39.DRY (Dont Repeat Yourself) 40.COMENTRIOS 41.Comentrios no ajudam um cdigo sujo! 42.Comentrios Em geral, servem para explicar um cdigo ruim. Um bom cdigo auto-documentado. Extraia para um mtodo que faa o que diz! 43.Comentrios aceitveis 44.Comentrios Comentrios sobre licena (direitos de uso de uma lib, por exemplo) Comentrios informativos Necessidade de explicao de negcio 45.Comentrios ruins 46.Comentrios Por falta do que escrever Redundantes Documentao em APIs no pblicas Dizendo algo que o prprio cdigo deveria dizer Cdigo comentado =S 47.Comentrios 48.FORMATAO 49.O que vale a regra do time 50.OBJETOS E ESTRUTURA DE DADOS 51.Abstrao de dados 52.Objetos e estrutura de dados 53.Objetos e estrutura de dados 54.A lei de Demeter 55.Objetos e estrutura de dadosUm mtodo F de uma classe C s conhece: Mtodos de C Objetos criados por F Objetos passados como argumentos para F Objetos em variveis de instncias de C 56.TRATAMENTO DE ERRO 57.Excees ao invs de cdigo de erro. 58.Tratamento de erro 59.Tratamento de erro 60.Tratamento de exceo uma dascoisas que um mtodo ou funo faz 61.No use excees genricas 62.No retorne null 63.Tratamento de erro Obriga o uso de if Pode dispara NullPointerException Considere: Lanar exceo ou retornar um objeto especial 64.No passe null 65.REGRA DOS ESCOTEIROSDeixe a rea do acampamentomais limpa do que como voc aEncontrou. 66.No deixe acumular problemas! 67.Cdigo ruimcheira mal...Torna o seutrabalho lento edesgastante com opassar do tempoPode arruinar seuprojeto, carreira,empresa...Fique atento. 68.Falar fcil! O desafio criar um cdigo de qualidade. Portanto, falar o primeiro passo de melhoria. 69.Using References;Gustavo Barbosahttp://www.slideshare.net/gustavocsbHendrik Ebelhttp://www.slideshare.net/hebelThiago Faria de Andradehttp://www.slideshare.net/thiagofa

A falsa impresso de um bom cdigoDesde de quando comecei a trabalhar com desenvolvimento de software, ouvia sempre uma frase que muito repetida at hoje que diz que: Cdigo bom cdigo comentado. Em conversas com outros desenvolvedores alguns reclamavam porque que se viam obrigados a comentarem seus cdigos para poderem passar pelas auditorias internas. Hoje vejo isso como um absurdo (para no dizer outra coisa). Muitos comentrios podem mesmo ser parmetro para definir um bom cdigo? Eu, particularmente sou defensor de um cdigo no comentado, ou com o mnimo de comentrios possvel. Muitos devem estar se perguntando agora, como assim, cdigo no comentado? Esse cara est ficando louco? Mas no falem mal de mim ainda vou explicar o meu ponto de vista.Um cdigo comentado quase sempre sinal de cdigo ruim. Se voc sentiu a necessidade de comentar seu cdigo porque at voc est percebendo que o mesmo no est expressivo e, todas as suas linhas no conseguem refletir o seu verdadeiro objetivo.Acredito que tem certos cdigos que realmente so difceis de serem expressivos, mesmo sendo refatorados. Podemos citar por exemplo, o uso de bibliotecas de terceiros que s vezes no apresentam o funcionamento esperado e, nesses casos somos obrigados a comentar determinados trechos, para facilitar a vida dos outros desenvolvedores que futuramente iro dar manuteno no cdigo. Um outro caso que tambm pode caber comentrios quando estamos desenvolvendo uma biblioteca para ser utilizada externamente, nessa situao os comentrios podem auxiliar o uso da biblioteca. Mas ainda permaneo com o pensamento que podemos sempre buscar alternativas para evitar os comentrios.Um cdigo muito comentado pode trazer outro problema: a manuteno do prprio comentrio. Sabemos da dificuldade que em muitos casos dar manuteno em um cdigo de produo, agora some a isso o esforo de atualizao tambm do comentrio.Seu cdigo deve ser expressivoPara tentar demonstrar um cdigo expressivo imaginei um exemplo onde seja necessrio implementar um mtodo que aplique descontos nas mensalidades dos alunos do 5 perodo ou superior, e que tenham o coeficiente de rendimento maior ou igual a 7.

Cdigo com necessidade de comentrioAbaixo apresento o mtodo AplicarDescontosMensalidades refatorado, com um cdigo mais expressivo.

Cdigo refatorado sem a necessidade de comentrioDepois de refatorar o cdigo do mtodo AplicarDescontoMensalidades, percebe-se que o mesmo est mais expressivo e o seu objetivo se mostra mais claro para quem l o cdigo do mtodo agora.Meu objetivo aqui no condenar totalmente os comentrios no cdigo fonte, mas sim levantar a questo que, mais importante que ter um cdigo muito comentado ter um cdigo expressivo, que diz a sua inteno tanto nos nomes dos mtodos que o compe, quanto nas suas linhas. Ao sentir a necessidade de fazer um comentrio, pare e reflita sobre a sua real necessidade, faa sempre as perguntas: Porque tem que ter esse comentrio? O cdigo fica claro sem o comentrio? Outros desenvolvedores iro entender mesmo esse cdigo? E se possvel procure sempre mostrar seu cdigo para outros desenvolvedores da equipe e receber feedbacks sobre o mesmo.Robert C. Martin (Uncle Bob) cita no seu livro Cdigo Limpo Habilidades Prticas do Agile Software, uma frase que diz muito sobre o pensamento que tenho: O nico comentrio verdadeiramente bom aquele em que voc encontrou uma forma para no escrev-lo. isso ai, espero que tenha conseguido passar o recado e que agora vocs analisem bem a real necessidade dos comentrios nos seus cdigos. Para qualquer feedback deixe seu comentrio, esse sim um tipo de comentrio que aceito e recebo com prazer.

Use comentrios com moderaoUse comentrios com moderaoEmbora seus comentrios no prejudiquem o funcionamento de seu programa em C, evite usar ele desnecessariamente, comentandoprintfe outras coisas bvias: 'agora exibimos a mensagem', 'agora somamos os nmeros' etc.

Use comentrios para explicar o que o programa, para que serve, qual a utilidade de um algoritmo que mais complexo, elaborado ou grande.

Cdigo Limpo

Todo programador em algum momento j se perguntou se realmente est gerando bons cdigos, na verdade esse pensamento deveria existir toda vez em que escrevemos qualquer trecho de cdigo, mas visando melhorar meu entendimento sobre o que um bom cdigo comprei o livro Cdigo Limpo, do autor Robert C. Martin,neste livro so apresentadas prticas boas e ruins de desenvolvimento, um timo lugar para aprender algumas prticas que sempre criaram dvidas, confira alguns exemplos de perguntas que sero respondidas aps a leitura. Ser que comento esse bloco de cdigo? Minha funo est objetiva? Ser que esse nome de varivel ficou bom? TDD atrapalha na expanso de um projeto?O autor tenta deixar bem claro que o objetivo no vender seu padro de desenvolvimento como uma verdade absoluta, ao invs disso Robert tenta mostrar como trabalha e o que acha uma boa prtica, alm de mostrar o que no gosta e consultar programadores responsveis por projetos e linguagens conhecidas para reforar seu ponto de vista.Cdigo LimpoO grande ponto de reflexo no se contentar em fazer um cdigo funcionar, pois segundo o autor,fazer um cdigo funcionar muito fcil, mas utilizar padres e facilitar o entendimento de um cdigo o que realmente faz de voc um bom programador.Sumrio Resumido1. Prefcio2. Introduo3. Sobre a Capa4. Cdigo Limpo5. Nomes Significativos6. Funes7. Comentrios8. Formatao9. Objetos e Estruturas de Dados10. Tratamento de Erro11. Limites12. Testes de Unidades13. Classes14. Sistemas15. Emergncia16. Concorrncia17. Refinamento Sucessivo18. CaractersticasInternas do JUnit19. Refatorando o SerialDate20. Odores e HeursticasNomes SignificativosNesse captulo o autor apresenta motivos para se escolher bons nomes, ou seja, nomes significativos para o contexto do cdigo, desde variveis at classes, sempre passando dicas e fazendo comparaes de cdigos com nomes significativos e cdigos com nomes confusos.Confira algumas dessas dicas: Evitar informaes erradas Faa distines significativas Use nomes pronunciveis No utilize abreviaesFunesPequenas, o que todas as funes devem ser, alm disso cada funo deve fazer apenas uma coisa. Basicamente se sua funo est grande ou faz mais de uma coisa, refatore seu cdigo, extraia funcionalidades diferentes de dentro da sua funo e crie uma nova, se for private coloque em baixo da funo que utilizar. Um ponto interessante nesse captulo quando o autor fala sobre os parmetros das funes, deixando bem claro que quanto menos parmetros melhor, sendo que nenhum parmetro o ideal, mesmo que isso sejadifcilde ocorrer.ComentriosOs pontos citados pelo autor sobre comentrios em cdigo so timos, em muitos casos comentrios so adicionados para aliviar aconscinciado programador aps ter feito um cdigo ruim, sendo assim, ao invs de escrever um comentrio,reescrevaseu cdigo. Tambm posso destacar a passagem de comentrios redundantes, principalmente em cdigos que no sero disponibilizados como API pblica, logo no necessrio utilizar documentao, Ex:Javadoc, ainda mais em variveis, coisa que o autor considerahorrvel.ClassesEste captulo tem alguns detalhes parecidos com os que foram vistos para funes, por exemplo, devemos seguir o princpio da responsabilidade nica, ou seja, cada classe s pode ser responsvel por uma coisa, se voc precisar descrever uma classe e utilizar as palavras se, e, ou ou mas, tenho ms notcias para voc, refatore seu cdigo, alm disso tambm recomendado organizar o cdigo de tal forma que faa valer o princpio de aberto-fechado, onde as classes so abertas para expanso, mas fechadas para alteraes.Traduo do LivroApesar de apresentar um excelente contedo, em certos pontos fiquei chateado pelos erros de traduo, infelizmente algo quase que comum em livrostcnicosestrangeiros.ConclusoEste livro no visa melhorar seus conhecimentos em uma determinada linguagem, mas ir ajudar muito na maneira de pensar antes de programar em qualquer linguagem, em diversos pontos do livro esclarecido que a verdadeira documentao de um projeto o seu cdigo, documentaotcnica,comentrios e etc, tudo isso est sujeito a erros, principalmente em cdigos que so alterados comfrequncia. O legado de seu projeto o seu cdigo, sendo assim, torne este maislegvel,no tente programar para provar que voc conhece recursos que ningum mais conhece, programe para o projeto e para sua equipe.