code-quality
tursodatabase/turso
Regras gerais de correção, padrões em Rust, comentários e como evitar o excesso de complexidade na engenharia. Ao escrever código, leve sempre esses aspectos em consideração.
...Expandir tudoSobre a qualidade do código
A code-quality é uma referência concisa de convenções de codificação para o projeto de banco de dados Turso (Limbo), que abrange as regras de correção, os padrões típicos do Rust e orientações sobre comentários e prevenção de over-engineering que os colaboradores devem seguir sempre que escrevem código. Seu princípio norteador é o fato de se tratar de um banco de dados em produção, onde a correção é primordial e um travamento é preferível à corrupção de dados, por isso ela codifica os hábitos que mantêm o conjunto de códigos seguro.
O guia estabelece regras de correção (sem soluções temporárias ou truques rápidos, use assert com frequência, cause travamento em estados inválidos que possam comprometer a integridade dos dados, leve em conta casos extremos) e padrões do Rust (faça com que estados ilegais não sejam representáveis, utilize correspondência exaustiva de padrões, prefira enums a strings/sentinels, minimize alocações no heap, escreva código otimizado para CPU). Ele oferece orientações concretas sobre instruções if — use assert!, retorne um erro ou unreachable! para ramificações que nunca deveriam ser executadas, em vez de ignorá-las silenciosamente — e regras de comentários que incentivam a documentar o “porquê” em vez do “o quê”, proibindo referências a conversas com IA e marcadores temporais. Também adverte para verificar cuidadosamente a ordem das mutações de índice em relação ao SQLite, a fim de evitar inconsistências, aponta para uma habilidade relacionada ao modelo async I/O e lista regras de limpeza para evitar código morto ou soluções incompatíveis com versões anteriores.
Ele se destina aos colaboradores do conjunto de códigos Rust Turso/Limbo e, de forma mais ampla, a qualquer pessoa que desenvolva em Rust em nível de sistema e deseje um checklist compacto de correção. Trata-se de documentação puramente consultiva — sem scripts, comandos, credenciais ou efeitos colaterais — sendo, portanto, totalmente inofensiva.
Perguntas frequentes
Qual é o princípio fundamental?
Trata-se de um banco de dados em produção, onde a correção é primordial; por isso, um travamento é preferível à corrupção de dados. As regras incentivam que erros sejam detectados claramente, em vez de continuar em um estado indefinido.
Como devo lidar com ramificações que nunca deveriam ocorrer?
Não as ignore silenciosamente. Use assert! com uma mensagem explicativa, retorne um erro ou utilize unreachable! — reserve instruções if/else simples para casos em que ambas as ramificações são caminhos esperados.
Quais são as regras de comentários?
Documente o “porquê” em vez do “o quê”, documente funções/estruturas/enums/variantes e evite comentários que repitam código, façam referências a conversas com IA ou contenham marcadores temporais como “added” ou “Phase 1”.
Ele se aplica além do Turso?
Foi escrito para o conjunto de códigos Rust Turso/Limbo, mas suas orientações sobre correção e padrões do Rust são amplamente úteis para trabalhos em Rust em nível de sistema.
Por que ele destaca as mutações de índice?
Porque a ordem de inserção, exclusão e resolução de conflitos deve corresponder à do SQLite; uma ordem incorreta causa inconsistências nos índices que são fáceis de passar despercebidas.
Core Principle
Production database. Correctness paramount. Crash > corrupt.
Correctness Rules
- No workarounds or quick hacks. Handle all errors, check invariants
- Assert often. Never silently fail or swallow edge cases
- Crash on invalid state if it risks data integrity. Don't continue in undefined state
- Consider edge cases. On long enough timeline, all possible bugs will happen
Rust Patterns
- Make illegal states unrepresentable
- Exhaustive pattern matching
- Prefer enums over strings/sentinels
- Minimize heap allocations
- Write CPU-friendly code (microsecond = long time)
If-Statements
Wrong:
if condition { // happy path} else { // "shouldn't happen" - silently ignored}
Right:
// If only one branch should ever be hit:assert!(condition, "invariant violated: ...");// ORreturn Err(LimboError::InternalError("unexpected state".into()));// ORunreachable!("impossible state: ...");
Use if-statements only when both branches are expected paths.
Comments
Do:
- Document WHY, not what
- Document functions, structs, enums, variants
- Focus on why something is necessary
Don't:
- Comments that repeat code
- References to AI conversations ("This test should trigger the bug")
- Temporal markers ("added", "existing code", "Phase 1")
Avoid Over-Engineering
- Only changes directly requested or clearly necessary
- Don't add features beyond what's asked
- Don't add docstrings/comments to unchanged code
- Don't add error handling for impossible scenarios
- Don't create abstractions for one-time operations
- Three similar lines > premature abstraction
Index Mutations
When code involves index inserts, deletes, or conflict resolution, double-check the ordering against SQLite. Wrong ordering causes index inconsistencies. and easy to miss.
Ensure understanding of IO model
- Async IO model
Cleanup
- Delete unused code completely
- No backwards-compat hacks (renamed
_vars, re-exports,// removedcomments)
Todos os arquivos
0 arquivosInstalar code-quality
Baixe e extraia os arquivos de habilidade para o seu diretório .claude/skills/.
Baixar ZIPClone o repositório e copie os arquivos da habilidade para o seu projeto.
git clone https://github.com/tursodatabase/turso/blob/main/.claude/skills/code-quality/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copiar





Lar
