Blog Bugginho Academy

Desbuggando #1 – Evitando atribuições e retornos em redundância

Na série “Desbuggando”, gostaria de iniciar essa série por aqui para comentar os famosos POGs postados na página do Bugginho Developer. Sim… Daqueles que você riu bastante, mas que possivelmente cometa erros parecidos sem perceber – ninguém é perfeito.

Vamos falar sobre as possíveis correções e melhores práticas de programação a partir desse tipo de postagem. Se curtiu a ideia, vamos juntos!

Introdução

No ano passado, o Bugginho Developer havia postado um lindo código que mostrava o seguinte:

Nenhum texto alternativo automático disponível.

Merecedor do famoso Selo Bugginho de Qualidade, essa é uma grande obra de arte feita por alguém que ainda não manja o significado de informação booleana (ou mesmo sobre checar se um valor é positivo ou negativo… quem nunca?).

Booleanos são informações binárias que, por este motivo, tem seus estados como: ativado ou desativado; conhecido em nosso mundo por true ou false, respectivamente.

Através do possível desconhecimento de que uma comparação sempre retorna um booleano, é comum encontrar códigos de desenvolvedores que realizam uma comparação em  if()  e retornam os ambos booleanos, como mostrado na postagem original. Esse mesmo tipo de problema ocorre na atribuição de variáveis, valendo-se do mesmo conceito. E acredite: é possível que você faça o mesmo, até hoje, e não perceba.

Só pra deixar claro, vamos usar Javascript como linguagem base – apesar de a imagem original ser em Java. Isso ainda ajuda a mostrar como esse tipo de situação pode ocorrer independente da linguagem em prática.

Comparações sempre retornam um booleano

É fácil compreender a razão, mas às vezes por um pequeno descuido você acaba esquecendo e cometendo esse tipo de erro (que é mais comum do que você possa imaginar). Só para ajudar na imaginação, pense no seguinte: se você compara algo, espera-se sempre uma resposta verdadeiro ou falso.

Por exemplo: “maçã tem cor de uva?” Se você respondeu “azul”, você está no caminho errado! Não só pelo fato de uma maçã não ser azul, mas por que a resposta ideial deveria estar entre verdadeiro ou falso.

Essa regra vale não só para  if() , mas também em alguns tipos de atribuições. A maioria das linguagens possuem o conceito de inline conditional statement (em português livre, declaração condicional em linha) – é uma versão abreviada do popular if() .

Logo, a melhor solução para um dos problemas da imagem seria utilizar esse método. Um simples return primeiroCaractere.equals("-")  resolveria o problema booleano – e dessa forma você garante que nosso querido Bugginho não use seu código como exemplo artístico na página oficial.

Mas e se a ideia é retornar false/true, inversamente falando? Bem, nesse caso, utilize o operador de negação (que geralmente é uma exclamação, e vem antes da expressão).

Certo… Mas onde estamos errando?

Não é bem um erro. Sendo assim, a própria imagem original não se trata de um erro, mas uma ocasião onde seria possível melhorar, tornando o código menos redundante. A situação mais comum é quando você precisa realizar uma atribuição, e faz algo como isso:

Percebe-se, ainda, a definição dupla da variável informacao (fora a atribuição). Em algumas linguagens isso já seria um problema.

Opção 1: atribuição de valor padrão, antes da definição da verdade

Este primeiro método requer que você realize uma atribuição de um valor padrão deixando a expressão com uma única responsabilidade: atribuir se verdadeiro. Recomenda-se essa opção quando um dos valores a serem atribuídos não é complexo e o outro sim. Por exemplo:

Dica importante: se a definição falsa for a mais complexa, inverta a posição das declarações – e lembre-se de tornar a expressão negativa.

Opção 2: atribuição em linha

Esse método é mais recomendado quando ambas as informações não são complexas. Essa opção utiliza um recurso chamado ternary operator (em tradução livre, operador ternário) – ele é uma espécie de if() , onde a informação após a interrogação é o se verdadeiro, e após os dois pontos é o se falso.

Importante: em algumas linguagens, como o PHP, temos o ternary operator shortcut (em tradução livre, atalho para operador ternário). Esse operador é uma forma abreviada do método acima, onde o se verdadeiro é a própria resposta da expressão, desde que esta resposta também seja verdadeira (nessa linguagem, alguns valores não booleanos também podem ser convertidos para false, permitindo que esse atalho possua algum sentido).

Opção 3: onde podemos manter como está

Ainda há o caso onde devemos manter o if()  como ele nasceu para ser… É o caso onde ambos os valores dependem de um processamento complexo para realizar a definição em uma única variável. Uma definição complexa é aquela de depende de algumas execuções para se obter o valor a ser utilizado. Por exemplo:

Conclusão

Na imagem original, o maior problema mesmo foi a verificação de se o valor é negativo. Como esse foi um erro de lógica, prefiri dedicar esse tópico em cima do problema de construção – ou seja, tratar dos booleanos. Vou pensar em um artigo para tratar problemas de lógica, mas ainda preciso pensar com cuidado.

Enfim, rir é sempre bom – e essa é uma das raízes do Bugginho –, mas é sempre interessante tentarmos visualizar uma solução de várias formas diferentes, e entender onde encaixá-las. Ninguém nasce sabendo e estamos aqui para aprender. Então aqui está um pedacinho de conhecimento que pude compartilhar com vocês e, a depender da repercussão, venho com outros temas e continuação para esta série.

Dúvidas, críticas, elogios… deixem nos comentários!

Até a próxima!

David Rodrigues

3 comentários

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • David, no caso, quando o retorno for bolleano o proprio if pode ser utilizado como retorno, nao precisa de atribuição a variavel, refatorando o exemplo

    Double numero = -8,9;
    return (numero<0);

    • No caso de um retorno como da imagem, sim. Mas também falei sobre atribuição de variavel, que é um conceito parecido (afinal, ambos podem ter condicional inline). Nesse caso, é possível organizar o código para tirar melhores proveitos. Abraços!

    • E ai Nilson, tranquilo? Sim, você está certo, mas se você ver na conclusão do artigo o David comenta sobre esse problema, deixando claro, inclusive, que esse era o maior problema do código, mas preferiu comentar apenas a questão do booleano. Ou seja, pelo que eu entendi, ele não quis alterar a primeira parte do código, uma vez que todo mundo percebeu o erro grotesco que tinha ali ahuahuahua.

Your Header Sidebar area is currently empty. Hurry up and add some widgets.