Receber por email
← Voltar para o catálogo

code-style

Enforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.

343estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add tobihagemann/turbo

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/code-style-tobihagemann/svg)](https://www.skillteca.com.br/skills/code-style-tobihagemann)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Code Style: Mirror, Reuse, Symmetry

When writing new code in an existing codebase, follow these principles:

  1. Mirror the surrounding code exactly: Match brace style, comment style, naming conventions, blank line spacing, code density, and level of detail by reading nearby code first.
  2. Reuse existing patterns: Find the closest analogous feature and replicate its structure (method decomposition, control flow, annotations, guard clauses). Don't introduce new patterns when an existing one fits.
  3. Reuse existing code: Before writing a new helper, check if an existing method can be reused or generalized. If a new helper is needed, model it after its closest sibling.
  4. Maintain symmetry: If adding fooB() parallel to fooA(), ensure naming, parameter order, and structure are symmetric. Rename fooA() if needed.
  5. Logical ordering: Place new methods, switch cases, and fields in the order that mirrors the existing grouping or business lifecycle, not just appended at the end.
  6. Default to no comment: Write code that self-explains through naming, extraction, and structure. When you reach for a comment, first try refactoring so it becomes unnecessary. Add one only for a load-bearing constraint the code cannot express (a hidden invariant, a workaround, a non-obvious performance characteristic). When in doubt, omit it.
Compartilhar X LinkedIn