Capítulo 3 : Funções Código Limpo - Robert Martin Funções Pequenas A primeira regra para funções é que elas devem ser pequenas. A segunda é que a primeira regra nunca deve ser quebrada. Com pouca experiência podemos perceber que é muito mais fácil dar manutenção, refatorar, documentar e aplicar testes em funções pequenas. Para Uncle Bob as funções deveriam ter entre 1 e 5 linhas. Blocos Os blocos de if, else, while, for entre outros, deveriam ter apenas uma linha que chama outra função. Chamar uma função facilita o entendimento do código quando são usados nomes descritivos. Permite também reduzir a indentação, melhorando a leitura e a compreensão das funções. Fazer apenas uma coisa e fazê-la bem! O princípio da responsabilidade única declara que uma função deve fazer apenas uma coisa, cumprindo bem o objetivo para o qual foi projetada. Porém o que é uma “coisa”? Uma série de pequenos passos pode ser uma “coisa só”. Porém, deve-se criar outra função quando é possível decompor um conceito maior (o nome da função) em uma série de passos menores. Não misturar níveis de abstração diferentes Para ter certeza que a função está fazendo apenas “uma coisa”, precisamos observar se toda a lógica dentro de nossa função está no mesmo nível de abstração. Misturar um nível de abstração mais alto com outro mais baixo pode deixar as coisas confusas, pois fica difícil discernir o que é essencial do que é apenas um detalhe. Por exemplo: a) Frite o Ovo; Pegue o arroz no armário; Lave o arroz; Seque o arroz; Frite o alho; Refogue o arroz; Coloque água fervente; Cozinhe o arroz; b) Frite o Ovo; Prepare o Arroz; Ler código de cima pra baixo Uma função bem escrita permite ser lida de cima para baixo, como um conjunto de tópicos ou uma narrativa; Regra decrescente : Cada função pode ser seguida pelas outras do próximo nível de modo que vá se descendo um nível de cada vez. Usar nomes descritivos Nomes extensos e descritivos são melhores do que nomes curtos e enigmáticos. Não tema fazer uma função com um nome longo. Padronize as convenções de nomenclatura dentro dos projetos de uma mesma empresa. Parâmetros de Funções Use um número pequeno de parâmetros, tente não ultrapassar o limite de 3. Quanto menos parâmetros mais fácil o entendimento da função e a realização de testes, pois são necessários menos combinações de parâmetros para garantir que a função funciona direito. Usar parâmetros boolean é um mal negócio, pois isso significa que a função faz duas coisas diferentes. Melhor criar duas funções e chamá-las em um if. Evitar parâmetros de saída. anexaRodape(s) anexa algo em s, ou coloca o s em algum lugar? Melhor escrever algo como s.anexaRodape(); Separação comando-consulta As funções devem fazer ou responder algo, mas não ambos. Isto é, a função deve alterar o estado de um objeto ou retornar informações sobre ele, mas quando faz as duas coisas ao mesmo tempo, isso gera confusão. Evite os efeitos colaterais. Se a função faz mudanças inesperadas em variáveis globais, ou em variáveis passadas como parâmetros, isso pode dificultar e gerar confusão no reuso ou na manutenção, levando a comportamentos estranhos. Prefira exceções a código de erros Retornar um código de erro no lugar do valor é uma leve violação da separação comando-consulta. Retornar exceções permite deixar o código do tratamento de erro separado do código. Extraia os blocos try catch em funções. Evite repetições Se um trecho de código se repete em mais de um lugar, extraia-o e o coloque em uma função. Isso facilita a alteração, pois ao invés de modificar vários trechos, será necessária apenas alterar um único lugar.