Ruff v0.16.0 – Atualizações novas significativas – 413 regras padrão, acima de 59
O Ruff v0.16.0 expande significativamente suas regras padrão de linting e formatação para Python (de 59 para 413), com o objetivo de oferecer à maioria dos projetos uma análise estática forte com quase nenhuma configuração. Desenvolvedores elogiam sua velocidade, abrangência e integração com fluxos de trabalho modernos e agentes de codificação por IA, mas discutem sobre padrões rígidos, mudanças quebradoras antes de um lançamento 1.0 e se a imposição automatizada de estilo melhora ou prejudica a legibilidade e o “artesanato” do desenvolvedor. O debate também aborda como o Ruff se compara a ferramentas em outros ecossistemas como Go e JavaScript, e a crescente expectativa de que as equipes padronizem fortemente ferramentas automatizadas para evitar discussões improdutivas sobre estilo de código.
Escopo das Alterações do Ruff v0.16.0
- As regras padrão saltam de 59 para 413; muitos veem isso como um grande ganho para configurações “zero-config” e novos projetos.
- Alguns relatam que o
--fixdo Ruff trata 90% dos problemas; outros veem apenas 10–30% como autocorrigíveis, com muitos novos achados em código antes “limpo”. - Os novos padrões incluem ordenação de imports e avisos sobre
except Exceptionamplo; alguns desenvolvedores consideram isso de alto valor, outros veem como ruído.
Impacto em Codebases Existentes e Estratégia de Atualização
- Há preocupação de que habilitar centenas de novas regras por padrão possa inundar projetos estabelecidos com avisos.
- Estratégias sugeridas: fixar versões do Ruff, adiar atualizações até a equipe ter tempo para corrigir problemas, ou desativar seletivamente regras na configuração.
- Uma proposta: um conceito de “state version” (como no Nix) para travar um conjunto de regras conhecido e optar por novos padrões mais tarde; outros argumentam que fixar a versão por projeto é suficiente.
Semver, Versionamento e Mudanças Quebradoras
- Frustração com o fato de o Ruff ainda usar 0.x enquanto faz mudanças quebradoras em releases menores.
- Outros observam que isso é explicitamente permitido pelo semver para 0.y.z e corresponde à política de versionamento documentada do Ruff, que prioriza a estabilidade da API para uma futura 1.0.
Linters, Estilo e “Arte vs. Consistência”
- Há uma forte divisão entre os que veem linting/formatting rigorosos como essenciais para consistência e clareza nos diffs, e os que o veem como “policiamento gramatical” que pode prejudicar a legibilidade ou a intenção.
- Críticos argumentam que auto-formatadores às vezes destroem estrutura ou comentários intencionais e não tratam problemas mais profundos de design.
- Defensores enfatizam menos discussões improdutivas em PRs, onboarding mais fácil em codebases grandes e melhor sinal-ruído em revisões, especialmente quando combinados com CI/pre-commit.
Coding Agentic e Linting
- Vários relacionam linting mais forte ao aumento de coding agents: linters dão aos agentes um alvo claro e ajudam a limpar codebases grandes e legadas.
- Outros relatam que agentes às vezes reagem exageradamente às regras de lint (por exemplo, apagando testes para satisfazê-las), reforçando que o julgamento automatizado sobre “qualidade de código” ainda é imperfeito.
Desempenho e Implementação
- A velocidade do Ruff é amplamente elogiada; usuários o comparam favoravelmente a linters baseados em Python e a configurações Go com várias ferramentas, especialmente em codebases grandes.
- Alguns acham notável, mas não surpreendente, que uma ferramenta para Python seja escrita em Rust; velocidade e robustez são citadas como razões.
Comparações com Outros Ecossistemas (Go, JS, etc.)
- Go é citado tanto como exemplo positivo (gofmt, análise integrada) quanto como ainda carecendo de um linter único, rápido e unificado, como o Ruff.
- A discussão contrasta ecossistemas rígidos, com ferramentas impostas (Go, Rust, JS+Prettier/Biome) com o tooling cada vez mais opinativo do Python (Black, Ruff, uv).