Quando você coloca o sinal do lado errado, nada funciona.
Eu já vi gente passar meia hora debugando um formulário porque o campo de validação estava pegando "menor que" quando deveria ser "maior ou igual". O erro não estava no código, estava na cabeça de quem escreveu a lógica. Sinais de maior que e menor que parecem óbvios até você precisar aplicar em um sistema que lida com faixas de temperatura, prazos de entrega ou controle de estoque. Aí a coisa complicada. O sinal de maior que (>) indica que o valor à esquerda é estritamente maior que o da direita. O de menor que (<) funciona no sentido oposto. O igual acompanhado (>= e
=) resolve a ambiguidade quando o limite exato precisa entrar na conta. Parece simples, mas a forma como esses sinais se comportam em expressões encadeadas muda completamente o resultado.
Como eu aprendi a usar sinais de maior que e menor que sem errar todo dia
Antes de começar a programar, eu trabalhava com planilhas de controle de qualidade em uma fábrica. Meu problema era validar lotes: cada peça precisava ter diâmetro entre 12,5mm e 13,0mm. Se usasse apenas > e <, peças exatamente nas bordas eram rejeitadas ou aprovadas indevidamente. A correção foi simples, mas levou duas semanas para perceber. Troquei os operadores por >= e
= e adicionei uma verificação de arredondamento porque o sensor entregava valores com seis casas decimais. Sem isso, 12,499999 era reprovado mesmo sendo dentro da tolerância. A regra prática que eu uso agora é: se o limite é rigoroso, use > ou <. Se ele é parte válida da condição, use >= ou
=. Nunca misture os dois no mesmo trecho sem justificativa clara, senão fica ilegível e propenso a erro.
Em programação, a ordem dos operandos importa muito. Muitos iniciantes escrevem coisas como 10 < x < 20 esperando que funcione como na matemática escolar. Em Python funciona, mas em C, JavaScript e Java isso gera erro de compilação ou lógica incorreta. Nesses casos, você precisa escrever (x > 10) && (x
20). Perde um pouco de elegância, mas o código vai rodar como esperado.
Pegadinhas que ninguém conta
Uma delas é o comportamento com valores nulos ou indefinidos. Em JavaScript, comparar null com números converte null para 0, o que pode dar resultados surpreendentes. Em SQL, NULL nunca é maior, menor ou igual a nada — ele é simplesmente desconhecido. Se você fizer WHERE valor > 10 em uma tabela com NULLs, esses registros são ignorados. Não estão acima de 10, não estão abaixo. Eles simplesmente não entram na conta. Outro ponto que causa confusão é a direção visual do sinal. A abertura sempre aponta para o valor maior. Eu sempre lembro disso desenhando o risco de um "mais" exagerado do lado aberto. Não é brilhante, mas funciona na hora do pânico antes de uma prova ou de uma revisão de código.
Em expressões booleanas encadeadas, a precedência também armazena armadilhas. Operadores de comparação têm precedência menor que aritméticos mas maior que operadores lógicos. Isso significa que a + b > c * d é interpretado como (a + b) > (c * d), não como a + (b > c) * d. Quem não lembra disso gasta tempo demais entendendo por que uma expressão simples está falhando.
Limitações reais desses operadores
Sinais de maior que e menor que só funcionam com grandezas comparáveis. Tentar comparar uma string com um número em linguagens fortemente tipadas gera erro. Em linguagens fracamente tipadas, a conversão acontece automaticamente e pode produzir resultados inconsistentes. O operador de igualdade estrita (=== em JavaScript) resolve isso em muitos casos, mas não em todos — comparar objetos por referência versus conteúdo é outro problema que os sinais de comparação tradicionais não resolvem. Para ordenação de strings, a comparação depende do collation do banco de dados ou da configuração de locale do sistema. "Bolo" pode ser menor ou maior que "abacaxi" dependendo de como o sistema trata acentos e maiúsculas. Se você precisa de ordenação consistente para produção, use funções específicas de sort com collation definida, não apenas os operadores > e
.
O outro limitante importante é a precisão de ponto flutuante. Comparar diretamente floats com > ou == é arriscado. Dois valores que teoricamente deveriam ser iguais podem diferir em casas decimais insignificantes devido ao armazenamento binário. O workaround usual é usar uma tolerância, tipo Math.abs(a - b)
0.0001, em vez de comparação direta.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Sinais de maior que e menor que no dia a dia prático
Se você está montando filtros em uma API, a regra é: use query params com prefixos claros. ?price_gte=50&price_lte=500 é mais legível e menos propenso a erro que tentar codificar os operadores diretamente na URL. Já vi times inteiros perdendo horas porque um desenvolvedor usou > onde deveria ser >= e o produto ficou fora de catálogo por causa de um valor de borda. Em SQL, a dica é sempre testar com valores de borda antes de submeter para produção. Execute uma query com o valor exato do limite e verifique se ele entra ou não nos resultados. Leva 30 segundos e evita dor de cabeça enorme depois.
Para quem está começando agora, o exercício mais eficiente é criar uma tabela verdade manualmente para cada combinação de operador e tipo de dado. Leva uns dez minutos e fixa de vez quando cada sinal deve ser usado. Depois disso, a maior parte dos erros simplesmente para de acontecer.
