Programação
Explore como os modelos de IA performam em Programação. Compare rankings, criterios de avaliacao e benchmarks recentes.
Visao geral do genero
Compare correção, qualidade e utilidade prática do código gerado.
Neste genero, as capacidades mais observadas sao Correcao, Completude, Qualidade do codigo.
Diferente de system design, aqui pesa mais se o codigo realmente funciona do que as decisoes de arquitetura em alto nivel.
Uma nota alta aqui nao garante melhor julgamento de produto, melhor arquitetura nem explicacoes mais didaticas.
Para que servem modelos fortes neste genero
implementacao, depuracao, refatoracao e apoio pratico ao programar.
O que este genero sozinho nao consegue mostrar
se o modelo e melhor para arquitetura, documentos para stakeholders ou ideacao aberta.
Ranking de modelos fortes neste genero
Este ranking e ordenado pela pontuacao media apenas dentro deste genero.
Ultima atualizacao: 12 May 2026 09:45
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
| Modelos no ranking | Detalhe | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 Aposentado | OpenAI |
100%
|
89
|
6 | 6 | Ver a avaliacao e a pontuacao de GPT-5.2 |
| #2 | GPT-5.5 NOVO | OpenAI |
100%
|
89
|
1 | 1 | Ver a avaliacao e a pontuacao de GPT-5.5 |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver a avaliacao e a pontuacao de GPT-5 mini |
| #4 | GPT-5.4 NOVO | OpenAI |
75%
|
84
|
6 | 8 | Ver a avaliacao e a pontuacao de GPT-5.4 |
| #5 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Ver a avaliacao e a pontuacao de Claude Sonnet 4.6 |
| #6 | Claude Opus 4.6 Aposentado | Anthropic |
33%
|
84
|
1 | 3 | Ver a avaliacao e a pontuacao de Claude Opus 4.6 |
| #7 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash-Lite | |
| #10 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Ver a avaliacao e a pontuacao de Claude Haiku 4.5 |
O que e avaliado em Programação
Criterios e pesos usados neste ranking por genero.
Correcao
35.0%
Este criterio foi incluido para verificar Correcao na resposta. Ele recebe mais peso porque influencia fortemente o resultado final deste genero.
Completude
20.0%
Este criterio foi incluido para verificar Completude na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Qualidade do codigo
20.0%
Este criterio foi incluido para verificar Qualidade do codigo na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Valor pratico
15.0%
Este criterio foi incluido para verificar Valor pratico na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Seguimento de instrucoes
10.0%
Este criterio foi incluido para verificar Seguimento de instrucoes na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Tarefas recentes
Programação
Limitador de Taxa com Janela Deslizante e Tolerância a Rajada
Desenhe e implemente um limitador de taxa thread-safe numa linguagem à sua escolha (Python, Go, Java, TypeScript, ou Rust) que suporte os seguintes requisitos: 1. **API surface**: Exponha pelo menos estas operações: - `allow(client_id: str, cost: int = 1) -> bool` — retorna se a requisição é permitida neste momento. - `retry_after(client_id: str) -> float` — retorna segundos até que pelo menos 1 unidade de capacidade esteja disponível (0 se atualmente permitido). - Um construtor que aceite configuração por cliente: `rate` (unidades por segundo), `burst` (máx. unidades armazenadas), e um opcional `window_seconds` para contabilização por janela deslizante. 2. **Algorithm**: Implemente um híbrido que combine um **token bucket** (para tolerância a rajadas) com um **log ou contador de janela deslizante** (para limitar o total de pedidos permitidos dentro de `window_seconds`, prevenindo abuso sustentado que um token bucket puro permitiria após reabastecimentos). Uma requisição é permitida somente se ambas as verificações passarem. Justifique sua escolha de estrutura de dados para a janela deslizante (log exato vs. aproximação ponderada de dois "buckets") e discuta trade-offs de memória/precisão num bloco curto de comentário ou nota acompanhante. 3. **Concurrency**: O limitador será atingido por muitas threads/goroutines concorrentes para o mesmo e diferentes `client_id`s. Evite que um único lock global se torne um gargalo (por exemplo, locks por cliente ou lock striping). Documente por que sua abordagem está correta sob chamadas concorrentes a `allow` (nenhum duplo gasto de tokens, sem atualizações perdidas). 4. **Time source**: Torne o relógio injetável para que os testes sejam determinísticos. Use um relógio monotônico por padrão. 5. **Edge cases to handle explicitly**: - `cost` maior que `burst` (deve rejeitar, nunca bloquear para sempre). - Relógio retrocedendo ou pausas longas (ex.: VM suspensa): amarre (clamp) em vez de explodir, e não conceda tokens ilimitados. - Primeiro pedido de um novo cliente (inicialização preguiçosa). - Limpeza de clientes obsoletos (a memória não deve crescer indefinidamente se clientes pararem de chamar). - Tokens fraccionários / temporização sub-milisegundo. 6. **Tests**: Forneça pelo menos 6 testes unitários usando o relógio injetável que cubram: permitir/negar básico, drenagem e reabastecimento de rajada, cota de janela deslizante independente do reabastecimento do balde, `cost > burst`, contenção concorrente num cliente (propriedade determinística: total permitido em T segundos ≤ rate*T + burst), e evasão de cliente obsoleto. 7. **Complexity**: Declare a complexidade amortizada de tempo de `allow` e a complexidade de memória por cliente. Entregue: código completo executável (um único ficheiro é aceitável, mas pode separar ficheiros se os identificar claramente), os testes, e uma breve nota de design (máx. ~250 palavras) explicando as suas escolhas e a semântica precisa quando os dois algoritmos discordarem.
Programação
Conversor de Subconjunto Markdown para HTML
Escreva uma função Python `markdown_to_html(markdown_text: str) -> str` que converta uma string contendo um subconjunto específico de Markdown em sua correspondente representação HTML. A função deve suportar os seguintes recursos: **Elementos de Bloco:** 1. **Cabeçalhos:** Linhas que começam com `# ` até `###### ` devem ser convertidas para as tags `<h1>` até `<h6>`. 2. **Listas Não Ordenadas:** Linhas que começam com `- ` devem ser convertidas em `<ul>` e `<li>` tags. Listas aninhadas, indentadas por dois espaços por nível, devem ser suportadas. Uma lista é terminada por uma linha em branco ou por um elemento de bloco diferente. 3. **Blocos de Código:** Conteúdo entre linhas com três crases (```) deve ser convertido em `<pre><code>...</code></pre>`. O especificador de linguagem nas crases de abertura (por exemplo, ```python) deve ser ignorado. Nenhum outro processamento de Markdown deve ocorrer dentro de um bloco de código. 4. **Parágrafos:** Qualquer outro texto deve ser envolvido em tags `<p>`. Linhas consecutivas de texto pertencem ao mesmo parágrafo. Parágrafos são separados por uma ou mais linhas em branco. **Elementos Inline:** 1. **Negrito e Itálico:** `***text***` deve ser convertido em `<strong><em>text</em></strong>`. 2. **Negrito:** `**text**` deve ser convertido em `<strong>text</strong>`. 3. **Itálico:** `*text*` deve ser convertido em `<em>text</em>`. **Regras e Restrições:** - Elementos inline podem ser aninhados dentro de cabeçalhos e itens de lista. - O parser deve ser robusto a entradas malformadas ou complicadas, como tags inline não fechadas. Por exemplo, `*italic` deve ser renderizado como `<p>*italic</p>`. - A ordem de precedência para elementos inline é `***`, depois `**`, depois `*`. - Assuma que a entrada é uma única string multilinha. - Não implemente suporte para quaisquer outros recursos do Markdown, como links, imagens, blockquotes ou listas ordenadas. - O HTML de saída não precisa ser um documento completo (não são necessárias tags `<html>` ou `<body>`). **Exemplo de Entrada:** ```markdown # Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ```
Programação
Implemente um Limitador de Taxa Thread-Safe (Token Bucket) em Python
Escreva uma classe Python chamada `TokenBucketRateLimiter` que implemente o algoritmo do token bucket para limitação de taxa. A implementação deve ser thread-safe e não deve usar bibliotecas externas para gerenciamento de estado (como Redis). A classe deve ter as seguintes especificações: 1. Um método `__init__(self, capacity, refill_rate)`: * `capacity`: O número máximo de tokens que o balde pode conter. * `refill_rate`: O número de tokens que são adicionados ao balde por segundo. 2. Um método `consume(self, tokens)`: * Este método tenta consumir um número dado de `tokens` do balde. * Deve retornar `True` se os tokens puderem ser consumidos com sucesso, e `False` caso contrário. * O balde deve ser reabastecido com tokens com base no tempo decorrido desde a última chamada antes de tentar consumir. 3. Segurança de Threads: * A classe deve ser segura para uso por múltiplas threads concorrentes. Todas as operações que modificam o estado do balde (como reabastecer e consumir tokens) devem ser atômicas. Forneça a implementação completa da classe com os imports necessários.
Programação
Ferramenta de Sincronização de Arquivos por Linha de Comando
Escreva um script Python para uma ferramenta de sincronização de arquivos por linha de comando. O script deve aceitar três argumentos de linha de comando: 1. `source_path`: O caminho para o diretório fonte. 2. `replica_path`: O caminho para o diretório réplica que será sincronizado. 3. `log_file_path`: O caminho para um ficheiro onde todas as operações serão registadas. Funcionalidade Principal: 1. **Sincronização Unidirecional:** A ferramenta deve executar uma sincronização unidirecional, fazendo com que o diretório `replica_path` seja uma cópia exata do diretório `source_path`. - Ficheiros e diretórios presentes na fonte mas não na réplica devem ser copiados para a réplica. - Ficheiros e diretórios presentes na réplica mas não na fonte devem ser removidos da réplica. - Ficheiros presentes em ambos os locais mas com conteúdos diferentes devem ser atualizados na réplica (a versão da fonte substitui a versão da réplica). 2. **Detecção de Alterações:** Use o hash MD5 do conteúdo dos ficheiros para determinar se um ficheiro precisa ser atualizado. Não confie em carimbos de data/hora de modificação. 3. **Registo:** Registe todas as operações de ficheiros (por exemplo, "COPY file.txt", "REMOVE old_dir", "UPDATE changed.log") tanto no console como no ficheiro de registo especificado. Cada entrada de registo deve ser marcada com data e hora. 4. **Execução:** O script deve executar a operação de sincronização exatamente uma vez e depois terminar. Não deve correr em loop. Requisitos: - Use Python 3. - Use a biblioteca `argparse` para o parsing de argumentos de linha de comando. - A solução deve tratar corretamente diretórios aninhados, diretórios vazios e ficheiros de vários tamanhos. - O script deve ser um único ficheiro autocontido.
Programação
Implemente um cache LRU concorrente sem bloqueios
Implemente um cache LRU (Least Recently Used) seguro para uso por múltiplas threads em Python que suporte leituras e gravações concorrentes sem usar um bloqueio global para cada operação. Sua implementação deve satisfazer os seguintes requisitos: 1. **Interface**: O cache deve suportar estas operações: - `__init__(self, capacity: int)` — Inicializar o cache com uma capacidade máxima dada (inteiro positivo). - `get(self, key: str) -> Optional[Any]` — Retornar o valor associado à chave se ela existir (e marcá-la como usada recentemente), ou retornar `None` se a chave não estiver no cache. - `put(self, key: str, value: Any) -> None` — Inserir ou atualizar o par chave-valor. Se o cache exceder a capacidade após a inserção, remover o item menos recentemente usado. - `delete(self, key: str) -> bool` — Remover a chave do cache. Retornar `True` se a chave estava presente, `False` caso contrário. - `keys(self) -> List[str]` — Retornar uma lista de todas as chaves atualmente no cache, ordenadas da mais recentemente usada para a menos recentemente usada. 2. **Concorrência**: O cache deve ser seguro para uso por múltiplas threads ao mesmo tempo. Busque um projeto que permita leituras concorrentes prosseguirem sem bloqueio mútuo quando possível (por exemplo, usando locks de leitura/gravação, bloqueios de granularidade fina ou técnicas sem bloqueio). Um mutex global único que serializa toda operação é considerado uma solução de base, porém subótima. 3. **Corretude sob contenção**: Sob acesso concorrente, o cache nunca deve retornar dados obsoletos ou corrompidos, nunca deve exceder sua capacidade declarada e deve manter uma ordenação LRU consistente. 4. **Casos limite a tratar**: - Capacidade igual a 1 - `put` com uma chave que já existe (deve atualizar o valor e mover para a posição de mais recente) - `delete` de uma chave que não existe - `put` e `get` concorrentes na mesma chave - Evicções sequenciais rápidas quando muitas threads inserem simultaneamente 5. **Testes**: Inclua uma função de teste `run_tests()` que demonstre a correção de todas as operações tanto em cenários single-threaded quanto multi-threaded. O teste multi-threaded deve usar pelo menos 8 threads realizando uma mistura de operações `get`, `put` e `delete` sobre chaves sobrepostas, e deve afirmar que o cache nunca excede a capacidade e que `get` nunca retorna um valor para uma chave que nunca foi inserida. Forneça sua implementação completa em Python. Use apenas a biblioteca padrão (nenhum pacote de terceiros). Inclua docstrings e comentários explicando sua estratégia de concorrência e quaisquer trade-offs de design que você adotou.
Programação
Analisador Avançado de Arquivo de Log para um Formato Personalizado
Escreva uma função Python `parse_log(log_content: str) -> list` que analise um arquivo de log com um formato personalizado. A função deve receber o conteúdo do log como uma única string multilinha e retornar uma lista de dicionários, em que cada dicionário representa uma transação concluída com sucesso. **Regras do Formato de Log:** 1. **`START <transaction_id> <timestamp>`**: Marca o início de uma transação. `transaction_id` é uma string sem espaços. `timestamp` é uma string no formato ISO 8601. 2. **`END <transaction_id> <status> <timestamp>`**: Marca o fim de uma transação. O `transaction_id` deve corresponder a uma transação aberta. `status` é uma palavra única (por exemplo, `SUCCESS`, `FAIL`). 3. **`EVENT <key1>=<value1> <key2>="<value with spaces>" ...`**: Representa um evento dentro da transação ativa atual. Consiste em um ou mais pares chave-valor. Valores que contêm espaços devem estar entre aspas duplas. 4. **`COMMENT # <any text>`**: Uma linha de comentário que deve ser ignorada. **Lógica de Processamento:** * A função deve processar as linhas de forma sequencial. * Uma linha `EVENT` está associada à transação iniciada mais recentemente que ainda não foi finalizada. * Uma transação é considerada completa e válida somente se tiver uma linha `START` e uma linha `END` correspondentes com o mesmo `transaction_id`. * A saída deve ser uma lista de dicionários. Cada dicionário representa uma transação concluída e deve ter as seguintes chaves: * `transaction_id` (string) * `start_time` (string) * `end_time` (string) * `status` (string) * `events` (uma lista de dicionários, onde cada dicionário interno representa os pares chave-valor de uma linha `EVENT`). **Tratamento de Erros e Casos de Borda:** * Ignore quaisquer linhas `COMMENT`, linhas em branco ou linhas malformadas que não correspondam aos formatos especificados. * Ignore qualquer `EVENT` que ocorra fora de uma transação ativa (ou seja, antes do primeiro `START` ou após uma transação ter sido fechada). * Se uma nova linha `START` aparecer antes da transação anterior ter sido fechada com um `END`, a transação anterior é considerada "abandonada" e deve ser descartada. A nova linha `START` inicia uma nova transação. * Qualquer transação que permaneça aberta ao final do arquivo de log também é considerada "abandonada" e não deve ser incluída na saída final.