O segundo Code Smell são os métodos longos, com dezenas ou centenas e às vezes milhares de linhas de código. É um problema extremamente frequente, especialmente nos programadores que praticamente só faziam(em) asps.

O problema dos métodos longos é, acima de tudo, a enorme dificuldade em compreender o que fazem, mesmo que tenham comentários. O problema reside no facto da distância semântica entre o que faz código e como o faz. Quando temos métodos longos, o que temos à nossa frente é o "como", mas "o que" temos nós de construir na nossa cabeça. Como bem sabemos, o nosso cérebro não tem recursos infinitos, pelo que quanto menos o esforçarmos com pormenores, mais ele se pode dedicar às actividades criativas e importantes.

Um príncipio fundamental de um bom programador tem de ser a clareza do seu código. Conseguimos ler o código ou temos de estudar e investigar o código? Este é um ponto fundamental, porque se o código for um esparguete desordenado, mantê-lo - e nunca nos esqueçamos que a manutenção começa na primeira linha de código que escrevemos - torna-se uma missão impossível. Onde eu trabalho, nós temos de viver com os sistemas que produzimos e por isso sentimos profundamente as questões da manutenção, para o bem e para o mal. Normalmente em equipas de projecto e de consultoria, esta questão não é tão premente...

Como sabemos que um método é demasiado longo? Existem dois sinais fundamentais: número de linhas de código (duh! tecla 3! outros...), se o método tiver mais de 10/15 linhas é um óptimo candidato a ser "desbastado"; o outro, mais polémico, é que quando julgamos ser necessário escrever um comentário para explicar um trecho de código devemos antes escrever um método.

De vez em quando, mais vezes do que seria desejável, ouço o argumento de que não vale a pena criar um método porque o código que constituiria esse método não é utilizado em mais lado nenhum. A consequência é que as classes costumam ter métodos públicos gigantescos, com alguns métodos privados que realizam as tais tarefas comuns. Regra geral, compreender estas classes só com muito "sangue, suor e lágrimas". Um método deve ser criado sempre que ajudar a tornar o código mais legível e fácil de manter. Hoje em dia, os compiladores possuem heurísticas que determinam quando um método deve ser tornado inline ou não, pelo que mesmo métodos com apenas uma ou duas linhas podem fazer sentido, desde que tornem o código mais legível. Além disso, muitas vezes só nos apercebemos do potencial de reutilização de uma secção de código quando a extraímos para um método próprio. Pelo menos, comigo isso acontece.

Como será mais ou menos de esperar, a esmagadora maioria das vezes, um simples Extract Method resolve o problema. Outras vezes, quando temos métodos com muitos parâmetros ou muitas variáveis locais, o Extract Method não basta, dado que os novos métodos provavelmente continuariam com longas listas de parâmetros ou variáveis temporárias. Para eliminar longas listas de parâmetros podemos tentar o Introduce Parameter Object ou o Preserve Whole Object. Para eliminar variáveis podemos usar o Replace Temp With Query. Se mesmo assim o problema se mantiver, existe sempre o Replace Method with Method Object.

Este post, à semelhança de todos os Code Smells, baseia-se no livro "Refactoring - Improving the Design of Existing Code". Ainda não o leram? Então de que estão à espera?