Um Aplicativo Requer Uma Função Que Retorne Verdadeiro

O problema que todo desenvolvedor encontra

Você já deve ter visto isso em algum requirement ou documentação: um aplicativo requer uma função que retorne verdadeiro. Na prática, isso não é mágica. É um padrão simples que muita gente complicam desnecessariamente. Basicamente, você precisa de uma função que, dada uma condição, devolva `true` ou `false`. Pode parecer óbvio, mas os erros começam quando a lógica interna fica confusa ou quando a função é chamada em momentos errados no fluxo da aplicação.

Por que um aplicativo requer uma função que retorne verdadeiro

Existem vários motivos. O mais comum é validação. Você quer verificar se um usuário está autenticado, se um campo foi preenchido corretamente, se um dado corresponde ao esperado. A função age como um guardião: ela responde sim ou não, e o resto do código toma decisões com base nisso. Outro caso frequente é em tests unitários. Frameworks como Jest, Mocha ou pytest dependem de funções que retornam `true` (ou melhor, valores truthy) para marcar um teste como aprovado. Se a função retorna `false` ou lança exceção, o teste falha. Isso é intencional e funciona bem na maioria das situações. Também vejo isso em APIs REST. Alguns endpoints retornam `{ "success": true }` como forma de confirmação de que a operação foi concluída. O cliente verifica esse campo e prossegue ou exibe um erro.

Como implementar na prática

Vamos ao código. A forma mais direta em JavaScript seria algo assim: function isValid(data) {
return data !== null && typeof data === 'object' && Object.keys(data).length > 0;
} Em Python:

def is_valid(data):
return data is not None and isinstance(data, dict) and len(data) > 0 Em Java: public boolean isValid(Object data) {
return data != null && data instanceof Map && !((Map<?, ?>) data).isEmpty();
}

A estrutura é sempre a mesma. Você define as condições, testa cada uma, e devolve o resultado booleano. O segredo não está na sintaxe, mas em entender exatamente quais condições precisam ser verificadas no seu contexto específico.

O erro que eu cometi e como resolvi

Há alguns anos atrás, eu estava desenvolvendo um sistema de permissões para um app interno. A função precisava verificar se o usuário atual tinha acesso a determinado recurso. Eu fiz a função retornar `true` quando o usuário estava logado e possuíía uma das roles necessárias. Funcionou localmente. Passou nos testes unitários. Foi para produção. Dois dias depois, o suporte recebeu uma reclamação: usuários com a role "editor" não conseguiam acessar páginas que normalmente poderiam. A função estava retornando `false` para eles. O problema? Eu estava comparando strings de role com `===`, mas os dados vinham do backend em maiúsculas (`"EDITOR"`) enquanto a função esperava minúsculas (`"editor"`). A comparação falhava silenciosamente. A solução foi simples: normalizei todas as strings para minúsculas antes da comparação.

return userRole.toLowerCase() === requiredRole.toLowerCase(); Esse tipo de problema é sutil. A função tecnicamente retorna verdadeiro ou falso corretamente, mas os dados de entrada estão em um formato que você não esperava. Sempre valide o formato dos dados antes de aplicar a lógica de comparação.

Informações técnicas que ninguém conta

Aqui vão dois pontos que eu aprendi na prática e que raramente aparecem em documentação básica. Primeiro: Evite funções que retornam `true` por efeito colateral. Isso é, uma função que além de retornar `true`, também modifica o estado da aplicação ou dispara outra operação. Isso torna o código difícil de testar e de depurar. Se você precisa de um efeito colateral, separe a vertação booleana da ação. Mantenha a função pura: entrada verificação saída booleana. Sem surpresas. Segundo: Cuidado com coerção implícita de tipos. Em JavaScript, por exemplo, `return 1` retorna um número, não um booleano. Em contextos que exigem `true` estritamente, isso pode causar problemas. Use `Boolean()` ou `!!` para garantir que o retorno seja mesmo um booleano:

return !!data; Isso converte qualquer valor para seu equivalente booleano. Vale null vira false. String não vazia vira true. Número diferente de zero vira true. Zero e NaN viram false. É previsível e evita bugs estranhos.

Limitações equando isso não funciona

Funções que retornam verdadeiro ou falso têm um problema fundamental: elas são binárias demais para certos cenários. Digamos que você precise validar um formulário com dez campos. Uma única função que retorna `true` ou `false` não diz nada sobre qual campo está errado. O usuário vê "inválido" e não sabe o que corrigir. Nesses casos, prefira retornar um objeto com detalhes do erro, ou use uma lista de mensagens de validação. A função pode continuar retornando `true` ou `false` para o fluxo principal, mas você deve ter outro mecanismo para extrair informações adicionais sobre o que falhou. Outro cenário onde funções booleanas simples falham é em sistemas concorrentes. Se duas requisições chegam ao mesmo tempo e a função verifica um estado compartilhado, você pode ter race conditions. A função retorna `true` para ambas, mas apenas uma deveria ter sucesso. Nesse caso, o problema não está na função em si, mas na falta de sincronização adequada no nível da camada de negócio ou do banco de dados.

Alternativas quando a função sozinha não basta

Se o seu caso é complexo, considere usar bibliotecas de validação como Zod, Joi ou Yup. Elas oferecem esquemas declarativos que podem gerar tanto o resultado booleano quanto mensagens detalhadas de erro. O custo é um pouco mais de configuração inicial, mas a manutenção fica significativamente mais barata. Para validações em tempo real, como em formulários, existem hooks como `useFormStatus` em React que já fornecem esse tipo de funcionalidade pronta. Não reinvente a roda se existe algo que já resolve o problema com testes passados e manutenção ativa. A regra geral é: comece com uma função simples que retorna `true` ou `false`. Deixe ela crescer apenas quando o problema exigir mais. Funções booleanas são úteis porque são simples. Quando elas param de ser simples, geralmente significa que o problema é mais complexo do que uma simples resposta sim ou não.