Estruturas condicionais (e seus riscos)

É comum, ao se iniciar os estudos em programação, que se trabalhe com estruturas de verificação de condição, os famosos blocos de if, else if (ou elif) e else.

De fato, esses são comandos fundamentais para qualquer tipo de aplicação, já que são eles que permitem ao programa, em seu processamento, "tomar decisões" a respeito dos valores de entrada e processá-los de acordo com essas decisões.

No entanto, conforme o número de condições verificada cresce, o código pode rapidamente ficar bastante confuso. Veja o exemplo abaixo, em Python, para uma função hipotética:

# Função que recebe o comprimento (em cm) de uma pessoa e retorna se o valor é válido

def valida_comprimento(medida):
valor_valido = False
if type(medida) == float:
  if medida >= 65.0:
    if medida <= 250.0:
      valor_valido = True
    else:
      print('Valor inválido, pois pessoa mais alta do mundo tem 250 cm!')
  else:
    print('Valor inválido, pois pessoa mais baixa do mundo tem 65 cm!')
else:
    print('Valor inválido, pois medida precisa ser passada em cm e ser do tipo float!')
return valor_valido

Certamente é muito fácil se perder nesse código, visto que há três níveis de aninhamento na estrutura condicional (ou seja, três ifs, um dentro do outro), cada um deles acompanhado por bloco de else que contém uma mensagem específica sobre o valor inválido. Além disso, utiliza-se uma variável para retornar se o valor passado é válido ou não.

O uso de early return

Mas como poderíamos melhorar esse código? Veja o exemplo abaixo:

# Função que recebe o comprimento (em cm) de uma pessoa e retorna se o valor é válido

def valida_comprimento(medida):
if type(medida) != float:
  print('Valor inválido, pois medida precisa ser passada em cm e ser do tipo float!')
  return False
if medida < 65.0 or medida > 250.0:
  print('Valor inválido, pois é maior ou menor do que os recordes de altura máxima e mínima. Se essa for sua altura, recomandamos procurar o Guiness Book!')
  return False
return True

Perceba que, nesse caso, não verificamos se o valor passado está dentro do esperado, mas o contrário. E por que disso? Ora, se o valor não obedecer às condições que determinamos, ele não nos serve, o que nos permite já retornar o valor booleano False (um retorno precoce, por isso o nome "early return") e sair da função, sem processamentos desnecessários.

Assim, além de invertermos a lógica de verificação, também incluímos três comandos return, sendo dois para os casos de valores inválidos, e um padrão, que retorna o valor esperado, caso nenhuma das verificações de invalidez seja verdadeira.

Além disso, esse estilo de programação também facilita a leitura do código, pois há menos aninhamento de blocos. Também fica claro qual é o valor esperado de retorno, caso o parâmetro passado esteja dentro das condições, pois basta um simples comando de return True após todas as verificações, dispensando o uso de uma variável redundante.

Ao tomar o caminho das negativas, ou seja, verificar se o parâmetro não está de acordo com desejado, conseguimos tornar o código mais claro e eficiente.

Outras considerações

É evidente que existem outras melhorias possíveis no código acima, como o uso de tratamento de exceções, conversão de tipos, reescrita das condições etc., mas o foco era mostrar como uma diferença sutil ao escrever o código pode facilitar o trabalho de desenvolvimento - que, devemos lembrar, é feito sempre em conjunto, e por isso devemos pensar não só se nosso código funciona, mas também se é legível.

Por fim, fica a sugestão de leitura a todas e todos sobre outros tópicos relacionados, como boas práticas, estilo de escrita de programação e paradigmas de programação, pois são um importante complemento ao estudo da sintaxe de uma linguagem e da lógica de programação.

Fontes

Return Early Pattern (https://medium.com/swlh/return-early-pattern-3d18a41bba8)

Return early (https://dev.to/jpswade/return-early-12o5)