O que é e quando usar
O operador de maior que (>) compara dois valores e retorna verdadeiro quando o da esquerda é estritamente superior ao da direita. Parece simples, mas na prática gera dúvidas que custam bugs caros, principalmente quando se mistura com tipos diferentes ou com dados vindos do usuário.
Qual o sinal de maior e como ele se comporta em situações reais
Em Python, JavaScript e a maioria das linguagens modernas, a sintaxe é direta: 5 > 3 avalia como True. O operador não modifica os operandos — ele apenas devolve um booleano. Mas tem uma pegadinha que eu levei semanas pra parar de levar: Em JavaScript, > faz coerção de tipo antes de comparar. Isso significa que "10" > 9 é verdadeiro porque a string vira número, mas "10" > "9" também é verdadeiro — e aí já entra a comparação lexicográfica quando ambos são string: "9" > "10" retorna true porque "9" vem depois de "1" no ordenamento de caracteres. Em Python isso não acontece: "9" > "10" dá erro de TypeError porque não se compara string com int diretamente. A diferença entre as linguagens causa erros silenciosos se você vier de um contexto e migrar pro outro sem prestar atenção.
No dia a dia eu trabalho muito com APIs que retornam valores numéricos como strings JSON. Já passei por um incidente onde uma regra de negócio que usava > num campo "preco" vinha vindo como "1500,99" (vírgula decimal, formato BR) e o sistema ia comparar strings em vez de números. O resultado era completamente errado. A solução foi garantir a conversão para float antes de qualquer comparação, e adicionar um teste unitário que passa exatamente esse formato como edge case.
Operadores relacionados
Além do maior que, existem variações que todo mundo usa, mas nem todo mundo domina na hora da depuração:
>=(maior ou igual): retorna true quando os valores são iguais ou o da esquerda é maior<(menor que): o inverso do maior que<=(menor ou igual): retorna true quando os valores são iguais ou o da esquerda é menor!=(diferente): comparacao de desigualdade===(igualdade estrita, JS/TS): compara valor e tipo sem coerção
No Python, a comparação encadeada é um recurso subutilizado que evita repetição. Em vez de escrever x > 5 and x < 10, você pode escrever 5 < x < 10. O interpretador avalia tudo de forma atômica, sem executar o meio termo duas vezes. Isso é particularmente útil quando o valor do meio é uma expressão custosa, como uma chamada de função ou um cálculo complexo.
Armadilhas comuns
O primeiro erro que eu vejo sendo repetido em code reviews é a confusão entre = e => (ou == e = dependendo da linguagem). Em C, C++, C#, Java e JavaScript, = é atribuição e == é comparação de igualdade. Já em Ruby, = é sempre atribuição e == é comparação. Em Python, = atribui e == compara. Erros de digitação nesse operador custam horas de debugging porque o código compila/executa normalmente, apenas com lógica errada. Outro ponto: NULL e NaN se comportam de formas inesperadas. Em SQL, qualquer comparação com NULL retorna UNKNOWN (que se propaga como false em WHERE). Em JavaScript, NaN > 0, NaN < 0 e NaN == NaN são todos false. Ou seja, NaN não é maior, nem menor, nem igual a nada, incluindo a si mesmo. Se você está filtrando dados numéricos e alguns valores vêm como NaN, o predicado x > threshold simplesmente não os seleciona — o que pode ser o comportamento esperado ou uma fonte de bugs, dependendo do caso.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Performance também merece mencao. Em loops quentes, cada comparação extra dentro da iteração custa. Não é que > seja lento, mas em Python puro, operações repetidas em milhões de iterações somam. Nesses casos, numpy ou pandas fazem a comparação vetorializada e o tempo cai de segundos para milissegundos. Eu vi um script que levava 47 segundosprocessando 5 milhões de linhas com um loop Python e > dentro dele. Migrando pra numpy.array(>), o tempo ficou em 0,3 segundos. A mudança não é só mais rapida — também é mais legivel, porque a intencao fica explicita no codigo.
Boas praticas
Sempre defina o tipo dos dados antes de comparar. Se a entrada vem de formulários web, API externa ou arquivo CSV, trate como string ate converter explicitamente. Usar float(), int() ou uma biblioteca de validacao como Pydantic antes de chegar no > evita comparacoes lexicograficas indesejadas. Quando comparacoes com zero ou limites fixos aparecem no codigo, coloque uma constante nomeada. if temperatura > LIMITE_MAXIMO: é mais claro do que if temperatura > 100:, especialmente quando o valor limite precisa mudar no futuro. Isso tambem facilita testes, porque voce pode substituir a constante por um valor arbitrario no ambiente de test sem tocar na logica principal.
Em JavaScript, prefira >>= apenas quando realmente precisar de coercao numerica intencional. Caso contrario, use Number() ou parseFloat() explicitamente antes da comparacao, assim o leitor do codigo sabe exatamente o que esta acontecendo. Comparacoes implícitas são a causa raiz de muitos tickets de bug que chegam na segunda-feira de manhã e ninguém entende direito o que aconteceu.
Um exemplo pratico rapido
Vamos supor que você tenha uma lista de dicionários com notas de alunos e quer filtrar aqueles cuja nota é maior que 7.0. Em Python:
alunos = [
{"nome": "Ana", "nota": 8.5},
{"nome": "Bruno", "nota": 6.0},
{"nome": "Carla", "nota": 7.0},
]
aprovados = [a for a in alunos if a["nota"] > 7.0]
result: [{"nome": "Ana", "nota": 8.5}]
Note que Carla, com nota exatamente 7.0, não entra na lista porque o operador é estritamente maior, não maior ou igual. Se a regra de negócio pede "7.0 ou mais", o correto é usar >=. Confundir esses dois operadores é um dos erros mais frequentes que eu vejo, e o impacto é direto nos resultados que o usuário final vê.
Resumo
O sinal de maior que é um operador fundamental, mas sua simplicidade escondees importantes sobre coercão de tipo, comportamento com valores nulos e NaN, e escolha entre comparações estritas e não estritas. Prestar atenção a esses detalhes desde o início economiza tempo de depuração e evita que regras de negócio sejam interpretadas de forma errada pelo sistema.
