50 Regras de Rust que Todo Especialista Deve Seguir
Um checklist mestre abrangendo segurança, design de API, async, performance e ferramentas. Use em revisões e onboarding.
Como Usar Esta Lista
- Leia todas as 50 regras de uma vez, depois aprofunde-se nos artigos vinculados para cada lacuna.
- Marque as regras que sua equipe aplica em CI ou no CONTRIBUTING.md.
- Releia após atualizações da toolchain ou edição.
Segurança e Correção (1-10)
- Minimize o escopo de
unsafe- isole em módulos pequenos com documentação# Safety. - Nunca use
unwrapna API pública de bibliotecas - retorneResult. - Use
?para propagação de erros - evite ruído dematchaninhado. - Prefira
try_fromem vez de castsasque perdem dados - especialmente para entrada do usuário. - Execute Miri/testes em código
unsafe- capture UB em CI quando viável. - Negue
unsafe_codeem crates de domínio - exceção única para crates FFI documentada. - Evite
panic!para controle de fluxo - useResultouOption. - Valide invariantes em construtores - estados ilegais não podem ser construídos.
- Use
checked_addpara aritmética influenciada pelo usuário - ou aumente os tipos. - Leve
#[deny(warnings)]a sério em atualizações da toolchain - corrija, não silencie globalmente.
Propriedade e Tipos (11-20)
- Use Newtype para IDs de domínio -
UserIdem vez deu64puro. - Empreste antes de
clone- profile clones em caminhos críticos. - Prefira
&strem vez deStringem argumentos - useimpl AsRef<str>quando flexível. - Use
Cownas fronteiras - empreste quando possível, possua quando necessário. - Enums em vez de pares de booleanos -
enum State { Draft, Live }em vez de dois booleanos. - Typestate para protocolos críticos - quando transições ilegais são custosas.
- Implemente
From/TryFrom- traits de conversão padrão. - RAII para recursos - arquivos, locks, guards.
- Evite teias de
Rc<RefCell>- redesenhe com propriedade ou canais. - Documente os requisitos de
Send/Sync- especialmente para limites genéricos.
Async e Concorrência (21-30)
- Não bloqueie workers do Tokio - use
spawn_blockingpara I/O síncrono. - Use
tokio::sync::Mutexem async - nãostd::sync::Mutexentreawait. - Defina timeout para chamadas externas -
tokio::time::timeout. - Limite a concorrência - use semáforos em fan-out.
- Entenda os limites
Sendem tarefas geradas -'static+Send. - Desligamento gracioso - sinalize e drene tarefas.
- Use canais para distribuição de trabalho - ciente de backpressure.
- Atômicos com ordenação correta - não
SeqCstpor padrão em tudo. - Evite globais mutáveis compartilhados - use
OnceLockpara configuração em vez disso. - Teste async com
#[tokio::test]- use tempo simulado compause.
Performance e Build (31-40)
- Meça builds de release - profile antes de otimizar.
- Use LTO fino para produção - ajuste com dados.
- Desabilite features de crates não utilizadas - builds mais rápidas, binários menores.
- Commite
Cargo.lockpara aplicações - deploys reproduzíveis. - Use
cargo clippy -D warnings- em CI. - Use
cargo fmt --check- zero debate de estilo. - Use Criterion para regressões em caminhos críticos - não adivinhação.
- Evite alocação em loops internos - reutilize buffers.
- Prefira iteradores até que se provem lentos - abstrações de custo zero.
- Dimensionamento correto de pools de conexão - pool
sqlxa partir de testes de carga.
API, Erros e Ecossistema (41-50)
- Siga a nomenclatura das Rust API Guidelines - convenções
as_,to_,into_. - Use
thiserrorem bibliotecas,anyhowem binários - política de workspace. - Erros estruturados com contexto - cadeia
error.source(). - Use
#[serde(deny_unknown_fields)]com Serde para entrada externa - quando seguro. - Flags de features documentadas - exemplos no README.
- Execute
cargo auditperiodicamente - higiene da cadeia de suprimentos. - Doctests em exemplos públicos - docs permanecem honestas.
- Testes de integração na API pública - não apenas testes unitários privados.
- Use ADR para forks de arquitetura - registre trade-offs.
- Prefira
stde crates bem mantidos - audite antes de adicionar dependências.
FAQs
Todas as 50 são obrigatórias?
As equipes progridem; comece com segurança, erros, CI (1-10, 41-48).
Como impor?
CI, métodos proibidos em clippy.toml, CODEOWNERS para crates unsafe.
Premium vs básico?
Todas as regras listadas são práticas básicas de especialista neste site.
Cadência de atualização?
Revise anualmente com a edição do Rust e incidentes da equipe.
Júnior vs sênior?
Júniors focam em 1-20; seniores são responsáveis por 21-50 e pela aplicação.
Links para aprofundamento?
Veja os artigos das seções: regras de unsafe, async, performance, erros.
Exceções?
Documente em ADR com o responsável e data de expiração.
Incorporar na contratação?
Use como rubrica de entrevista para cargos de Rust em sistemas.
vs clippy?
As regras se alinham com o clippy; clippy automatiza um subconjunto.
50 é suficiente?
Ponto de partida; a equipe adiciona regras específicas da organização (51+).
Relacionados
Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.