Formatador Python

Formatador Python - Formatar Python Online

Ferramenta de formatador Python online que ajuda você a formatar e embelezar código Python.

O que é PEP 8 e por que importa?

PEP 8 é o Guia Oficial de Estilo Python escrito por Guido van Rossum e outros em 2001 (última revisão em 2013). Define indentação (4 espaços, nunca tabs), comprimento de linha (79 caracteres para código, 72 para comentários), convenções de nomes (snake_case para funções e variáveis, PascalCase para classes, UPPER_SNAKE para constantes), agrupamento de imports (biblioteca padrão, terceiros, locais — separados por linhas em branco) e regras de espaçamento. A conformidade com PEP 8 torna o código Python instantaneamente legível em toda a comunidade. Ferramentas como `flake8`, `pylint` e `black` automatizam a verificação e a maioria dos pipelines CI falha em violações. Ler PEP 8 com atenção é a coisa mais impactante que um iniciante pode fazer.

Como o Black difere de autopep8 ou yapf?

Black é um formatador opinionativo que toma quase todas as decisões estilísticas por você — sem configuração, sem debate. Ele impõe linha de 88 caracteres, aspas duplas (não simples), vírgulas finais em coleções multilinha e espaçamento específico em torno de operadores. autopep8 só corrige violações PEP 8 de forma conservadora, deixando a maior parte da formatação original. YAPF (Yet Another Python Formatter) é configurável como autopep8, mas mais agressivo. Black é hoje o padrão de fato em 2025, usado por Django, FastAPI, pytest e a maioria das bibliotecas. O trade-off: o Black sobrepõe preferências pessoais, mas o tempo economizado em revisão e a consistência entre projetos compensam mais do que o suficiente.

O que é type hinting e PEP 484?

PEP 484 (2014) introduziu type hints estáticos opcionais no Python: `def saudacao(nome: str) -> str:` declara que `nome` é uma string e a função retorna uma string. Type hints não são impostos em tempo de execução — Python continua dinâmico — mas ferramentas como `mypy`, `pyright` e recursos de IDE os usam para análise estática, autocompletar e refatoração segura. PEP 585 (Python 3.9+) permite tipos genéricos nativos como `list[int]` em vez de `List[int]` do módulo `typing`. PEP 604 (Python 3.10+) adicionou `int | str` como sintaxe de união, substituindo `Union[int, str]`. Bases de código modernas se beneficiam enormemente: bugs em produção caem e o auxílio da IDE melhora drasticamente.

Qual a diferença entre formatar e linting?

Formatar muda como o código parece — espaços, quebras de linha, estilo de aspas — sem alterar comportamento. Linting analisa o código em busca de bugs, violações de estilo e code smells sem alterá-lo: imports não usados, variáveis não definidas, funções complexas, problemas de nomes. Black é formatador; pylint, flake8 e ruff são linters. Muitos projetos rodam ambos no CI: formatam com Black no commit, fazem lint com ruff/flake8 no push. Ruff (baseado em Rust, 2022) ficou popular rápido porque roda 10-100× mais rápido que flake8 + isort + pyupgrade juntos e consolida todas essas regras em uma só ferramenta. O ecossistema Python converge para Black + Ruff como cadeia de ferramentas padrão.

Por que tabs vs espaços são polêmicos no Python?

A gramática do Python trata a indentação como sintaticamente significativa — indentação ruim é SyntaxError ou, pior, IndentationError que altera o significado silenciosamente. Misturar tabs e espaços no mesmo bloco (legal no Python 2) causava bugs sutis e foi proibido categoricamente no Python 3 (PEP 8 + PEP 666). PEP 8 exige 4 espaços por nível de indentação e diz explicitamente 'espaços são o método de indentação preferido'. Tabs só são permitidos para manter consistência com código já indentado por tabs. A maioria dos editores converte a tecla Tab em 4 espaços quando configurada. Misturá-los num arquivo dispara erros `python -tt` e impede a execução.

Como minifico código Python e é útil?

A minificação Python remove comentários, docstrings e espaços para reduzir o tamanho do arquivo-fonte. Ferramentas como `pyminifier` e `python-minifier` fazem isso. Casos de uso: distribuir scripts de arquivo único onde o tamanho importa, sistemas embarcados com armazenamento limitado, desafios de code golf e AWS Lambda onde tamanho menor do pacote significa cold-start mais rápido. A economia costuma ser de 20-40 por cento. Note que o Python compila para bytecode .pyc automaticamente — o tamanho e a velocidade do bytecode não são afetados pela minificação do fonte. Para a maior parte do código de produção, legibilidade supera a pequena economia; só minifique quando o tamanho de distribuição importar de fato. Ferramentas como `mypyc` e `Cython` trazem ganho real de desempenho, diferentemente da minificação.

O que são docstrings e que convenções existem?

Docstrings são strings entre aspas triplas como primeira instrução de um módulo, classe ou função. PEP 257 (2001) define convenções: docstrings de uma linha terminam com ponto e cabem em 79 caracteres; multilinha usam um resumo na primeira linha, depois linha em branco, depois detalhes. Existem três formatos populares para documentar parâmetros: estilo Google (`Args: x: descrição`), estilo NumPy (`Parameters\n----------\nx : int`) e reStructuredText/Sphinx (`:param x: descrição`). Sphinx, MkDocs e Read the Docs geram documentação de API automaticamente a partir das docstrings. Black não reformata docstrings (preserva o formato exato), mas `docformatter` e `pydocstyle` validam e corrigem problemas comuns.

Como devem ser organizados imports no Python?

PEP 8 exige imports no topo do arquivo (depois do docstring do módulo, antes de qualquer código), agrupados em três seções separadas por linhas em branco: 1) biblioteca padrão (`import os`), 2) pacotes de terceiros (`import requests`), 3) aplicação/biblioteca local (`from .models import User`). Dentro de cada grupo, em ordem alfabética. `isort` automatiza a organização; `ruff --select I` é o equivalente moderno muito mais rápido. Star imports (`from module import *`) são desencorajados porque poluem namespaces e quebram o autocompletar da IDE. Use imports explícitos ou `from module import (\n name1,\n name2,\n)` para muitos nomes. Imports tardios dentro de funções são aceitáveis quando necessários para quebrar dependências circulares.

O que faz a Verificação PEP 8 integrada?

O botão Verificar PEP 8 executa uma varredura estática rápida, com números de linha, sobre o seu código bruto, inteiramente no navegador, e relata violações de estilo concretas como o flake8 ou o ruff fariam na CI. Ele aponta: indentação que mistura tabs e espaços, linhas indentadas com tab (PEP 8 prefere 4 espaços), linhas com mais de 79 caracteres, espaços finais, várias instruções separadas por ';', cláusulas 'except:' vazias, imports curinga 'from x import *' e linhas em branco ausentes entre definições def/class de nível superior consecutivas. Você recebe um resumo de aprovado/reprovado mais uma lista por regra com números de linha exatos, para corrigir antes do commit sem rodar uma ferramenta no servidor.

Substitui o Black, o ruff ou o autopep8?

Não, e essa distinção importa. Black, autopep8, ruff e yapf são ferramentas baseadas em AST que parseiam o código em uma árvore de sintaxe e o reescrevem, podendo reescrever expressões, quebrar linhas longas e reordenar imports com segurança. Esta ferramenta é um utilitário de reindentação e verificação no navegador: normaliza a indentação (tabs para espaços, reescalada para o tamanho escolhido) preservando o aninhamento relativo e o conteúdo literal das strings de aspas triplas, adiciona linhas em branco PEP 8, destaca a sintaxe e roda a verificação PEP 8 com números de linha. Nunca executa nem envia seu código. Use-a para limpezas rápidas e uma checagem antes do commit; mantenha Black + ruff na sua CI para a formatação e o linting definitivos.

Recursos Principais

• Formatar Python com indentação personalizável
• Destaque de sintaxe
• Processamento no navegador