Maior Que Ou Menor Que

Entendendo os sinais de desigualdade na prática

Se você já tentou escrever um código de validação ou montar uma consulta SQL e errou o sentido do sinal, provavelmente está sozinho nessa. Eu perdi horas debuggando um filtro que deveria puxar registros com valor maior que 100 e na verdade estava buscando menores, simplesmente porque o operador estava invertido. O problema é que maior que e menor que parecem óbvios até a primeira vez que algo quebra em produção. O símbolo maior que (>) verifica se o operando da esquerda excede o valor do lado direito. O menor que (

) faz o oposto. Parece trivial, mas a forma como diferentes linguagens e ferramentas interpretam esses operadores pode variar sutilmente, especialmente quando tipos de dados entram na equação.

Como saber se é maior que ou menor que sem errar

O truque que eu uso é simples e visual: imagine uma boca de crocodilo. O lado que abre mais largo é o maior, o lado pontiagudo aponta para o menor. É aquela mnemônica de escola, mas funciona porque não exige decoreba. Quando eu vejo 5 > 3, eu vejo o crocodilo comendo o 5. Quando vejo 3

5, o crocodilo come o 5 pelo outro lado. A geometria do símbolo já te dá a resposta sem precisar lembrar regras. Em programação, a coisa fica mais séria. Python usa > e < exatamente como esperado, mas tem o detalhe de que comparação entre tipos incompatíveis — string com número, por exemplo — lança erro em vez de converter automaticamente. JavaScript é pior nessa parte porque às vezes converte sozinho de formas que ninguém pede, então "10" > 5 pode ser verdadeiro enquanto "2" > 10 também é, porque a conversão de string para número em certas circunstâncias quebra.

No SQL, o operador funciona de forma consistente na maioria dos bancos, mas aqui existe uma armadilha que todo mundo encontra pelo menos uma vez: valores NULL. Nenhuma comparação com NULL retorna verdadeiro ou falso — retorna NULL. Então WHERE salario > 5000 não vai incluir nem excluir linhas com salário NULL, elas simplesmente somem da consulta. Eu passei dois dias caçando dados "desaparecidos" até perceber que a coluna tinha NULLs e meu filtro estava filtrando exatamente o que eu não queria filtrar. A solução foi adicionar explicitamente IS NULL ou COALESCE dependendo do objetivo.

Operadores compostos e os erros mais comuns

Além dos sinais básicos, existem o >= (maior ou igual) e <= (menor ou igual). A diferença prática é enorme em lógica de negócio. Em um sistema de desconto onde "compras acima de R$100 ganham frete grátis", usar > ignora exatamente quem comprou R$100,00. Usar >= captura todos. Eu vi isso acontecer em código real, duas vezes no mesmo mês, em dois projetos diferentes. A diferença é um caractere e o resultado é completamente errado. Em planilhas, a maioria das pessoas usa a função SE combinada com > ou

, mas esquece que a avaliação é feita em cadeia. Se você tem uma condição aninhada complexa, o Excel ou Google Sheets avalia da esquerda para a direita e para na primeira que encontrar. Isso significa que a ordem dos seus testes importa. Começar pelo mais restritivo geralmente otimiza, mas também pode esconder bugs se o primeiro teste capitur algo que deveria ser tratado pela segunda condição.

Uma nuance que pouca gente conhece é sobre ordenação lexicográfica versus numérica. Quando você compara strings com esses operadores, o resultado depende da tabela de codificação de caracteres. Em ASCII e Unicode, "B" é maior que "a" porque letras maiúsculas vêm antes das minúsculas. Então "banana" < "apple" pode retornar verdadeiro em algumas implementações porque 'b' > 'a' não é o único fator — o primeiro caractere já decide. Isso é especialmente traiçoeiro em ordenação de nomes ou códigos alfanuméricos.

Implementação em diferentes contextos

Em Python, a comparação encadeada é um diferencial útil: você pode escrever 10 < x < 20 e o interpretador traduz isso automaticamente para (10 < x) e (x

20). Isso não funciona em todas as linguagens. Em C e C++, o mesmo código produz comportamento indefinido ou erro de compilação, dependendo do contexto. Se você migra de Python para alguma linguagem mais baixa nível, esse tipo de atalho não existe e precisa ser reescrito explicitamente. Em JavaScript, o operador de igualdade estrita (===) versus frouxa (==) já é uma armadilha conhecida, mas a combinação com > e < cria situações ainda piores. A expressão "10" == 10 é verdadeira, mas "10" > 9 é verdadeira enquanto "10"

9 pode dar resultados inesperados dependendo do motor de execução. O conselho prático é sempre usar tipagem estrita ou converter explicitamente com Number() antes de comparar.

Em SQL, uma dica que economiza tempo: ao usar > e < em colunas indexadas, o otimizador do banco consegue usar o índice normalmente. Mas se você envolver a coluna em uma função — tipo WHERE YEAR(data) > 2023 — o índice é ignorado e a consulta escaneia a tabela inteira. Eu vi consultas que levavam 3 segundos virarem 45 segundos porque alguém escreveu uma condição comparável de forma que impediu o uso do índice. A correção foi transformar para WHERE data >= '2023-01-01' AND data

'2024-01-01', que é funcionalmente idêntico mas mantém a sargability da query.

Vantagens, limitações e quando não usar

O uso de comparação simples com maior que ou menor que é rápido, legível e amplamente suportado. A desvantagem é que ele não captura contexto. Se você precisa validar se um valor está dentro de uma faixa aceitável com tolerância de margem, uma sequência de > e

fica verbosa e propensa a erro. Nesse caso, uma função que calcule o intervalo ou um validador dedicado é mais limpo e menos propenso a bugs. Também não funciona bem quando os dados são qualitativos e não qualitativos. Comparar "excelente" > "bom" depende inteiramente de como você mapeia os rótulos para números. Sem um mapping explícito, a comparação é absurda. Eu já vi gente tentar ordenar categorias textuais diretamente e se surpreender com o resultado.

A alternativa quando a coisa fica complexa é usar bibliotecas de validação como Joi para JavaScript, Pydantic para Python, ou constraints definidas no DDL do banco. Elas centralizam a lógica de comparação e evitam que ela se espalhe pelo código como operadores soltos que ninguém revisa. O custo é um pouco mais de configuração inicial, mas o retorno em manutenção é alto. Se o seu cenário envolve floating point, há outra camada de complicação. O valor 0.1 + 0.2 em várias linguagens não é exatamente 0.3. Então uma comparação direta com > ou

pode falhar para valores que teoricamente seriam iguais. A correção padrão é usar uma epsilon de tolerância em vez de comparação direta. Isso é particularmente relevante em cálculos financeiros e científicos, onde a precisão importa.

O que eu diria para quem está começando agora é: aprenda o símbolo, memorize com o crocodilo, mas preste atenção redobrada no tipo de dado que está comparando e se NULL pode estar na sua base. Esses dois pontos são onde a maioria dos erros aparece no mundo real, não na confusão entre > e < em si.