Insights de código limpo – Funções

No capítulo 3 do livro “Código limpo – Habilidades práticas do agile software“, tio Bob explica diversos conhecimentos para a escrita de funções. Minha ideia hoje é repassar alguns desses conhecimentos.

Uma das primeiras considerações é sobre as funções serem pequenas, (funções que não ultrapassem o limite do monitor ou ainda menores). Funções pequenas também consideram poucos blocos e identação. Funções pequenas facilitam a leitura do código e fazem somente o necessário.

Ao falar sobre funções pequenas, Bob também explica a importância das funções fazerem somente uma coisa. O recado aqui é:

AS FUNÇÕES DEVEM FAZER UMA COISA. DEVEM FAZER ISSO BEM. E DEVEM FAZER SOMENTE ISSO.

Em casos em que seções são identificadas em funções, isto significa que provavelmente tais funções estão fazendo mais do que somente uma coisa. E aí, é hora de refatorar.

E ainda, funções devem respeitar diferentes níveis de abstração (desde o alto até o baixo nível).

Outro ponto importante sobre a escrita de código, incluindo funções, é que o código deve ser escrito para que seja lido de cima para baixo, onde funções de mais alto nível de abstração estão mais no topo, chamando funções de médio nível de abstração, e estas (exibidas mais para o meio do código), enfim chamam as funções de mais baixo nível. Desta forma o código fica simples de ser lido e as funções fazem sentido ao serem lidas.

Retomando o capítulo 2, onde Bob fala de nomes significativos, o mesmo é sugerido para a escolha de nomes de funções, os quais devem ser descritivos, ou seja, devem descrever exatamente o que tal função executa.

Bob comenta também que o ideal é que funções não possuam argumentos, mas que quando necessário, que o número de argumentos de uma função seja sempre o menor possível (1, 2 ou no máximo 3). Funções com muitos argumentos confundem a leitura do código e são propensos a erros, por esquecermos de tratar alguma situação (combinação dos diferentes argumentos). E quando existe a necessidade de se passar muitos argumentos à uma função, o melhor é o uso de um objeto, que abstrai todos os dados sendo enviados. Além disso, o ideal é que os argumentos sejam sempre inputs das funções, deixando os outputs para os retornos das mesmas.

Uma dica boa de nome de função quando a mesma recebe um argumento, por exemplo, é que a função seja nomeada com um verbo, e o argumento como um substantivo, como no exemplo abaixo:

escreve(nome)

Assim, fica fácil entender o que tal função faz com o argumento recebido.

E para finalizar, outro ponto importante sobre a escrita de funções é o conceito DRY (Don’t repeat yourself). Não se repita. Funções são escritas, dentre outras coisas, para fazerem o trabalho repetitivo. Ou seja, se você vê códigos duplicados por aí, pense em um momento para sua refatoração, pois muita duplicidade de código pode ser transformada em funções, e então o código será mais fácil de ler e de ser mantido.

Pense em seu código e nas suas funções como uma história que você quer contar e não simplesmente como algo que será lido por programadores.

Está gostando da série? Deixe um comentário!