Configuration

Configure formatters for consistent code quality

Formatters in QuantenRam aren't just cosmetic. They reduce noise in diffs, enforce shared readability in teams, and create a neutral basis for reviews. When you consciously choose and enforce formatters, you save significant time in understanding, debugging, and approving in real workflows.

The biggest mistake with formatting is half-configuration. If a project theoretically has a formatter, but contributors use different IDE settings, line endings, or tab widths, you get exactly the chaotic state the formatter was supposed to prevent. Good formatter configuration is always project-wide, versioned, and automatically enforced.

Define formatter in repository

Formatter configuration belongs in the repository, not in personal IDE settings. A file like .prettierrc, .black, or a comparable project file ensures that every clone and every agent sees the same standard. This prevents local preferences from fragmenting the team result.

Enforce via pre-commit or CI

Formatters should not be optional. A pre-commit hook or CI step that blocks on format errors ensures only cleanly formatted code reaches the repository. This is more convenient than later reformatting in reviews and prevents format commits that obscure the actual work.

Keep agents and formatters in sync

When working with agents, they should know and apply your project's formatter. In QuantenRam, this means Rules or Commands explicitly name the formatter and structure agent outputs accordingly. This keeps code proposed by agents consistent with human contributions.

Select formatters for different languages

Not every formatter fits every project. Selection should be based on community standard, speed, and configurability. However, consistency is more important than the specific choice: once chosen, the formatter should apply to the whole project, not be suspended for individual files or folders.

// .prettierrc - Example for JavaScript/TypeScript
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5"
}

For Python, Black has established itself as the standard because it allows little configuration and thus eliminates discussions about style. For Rust, rustfmt is the clear choice because it's official and consistently integrated. The decision should always aim for new contributors to know what to do without reading long documentation.

Combine formatter and review workflow

The ideal review process separates content changes from formatting changes. When formatters are strictly enforced, no one has to say "missing space here" in review. Instead, reviewers can focus on logic, architecture, and risks. This not only speeds up the process but also raises the quality of discussions.

# .github/workflows/format.yml - Example CI check
name: Format Check
on: [push, pull_request]
jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Check formatting
        run: |
          npm ci
          npm run format:check

In QuantenRam, you can define Commands that apply formatters before proposing. A command like /format-and-propose runs the formatter and then presents the diff. This ensures agent proposals always meet project standards without you having to reformat manually.

When you configure formatters, think about the goal: everyone on the team should see the same code, whether human or agent. Formatters exist to end formatting questions, not to open new debates.