Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 11 additions & 5 deletions AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,11 @@

Instruction for agents in this project, only to be modified by a human unless instructed otherwise. See https://agents.md.

## Conversation Style

Use "ASD-STE100 Simplified Technical English" as your conversation style; concise but detail-rich


## Build
```bash
cargo run -- <files> # Compile files
Expand All @@ -16,9 +21,10 @@ Guidelines (not mandatory but helpful for bigger changes)


## Code style
1. Do not eagerly add `#[derive(...)]` implementations like a `Debug` or `Clone`. Only add them when needed.
2. Avoid section and header comments like for example `// -- Types ---------`; use `// Types` instead if it truly makes sense.
3. Define all Rust structs, enums, etc.. first (in logical order) followed by their `impl` blocks in the same order.
1. Make code self-explanatory, keep changes as minimal as possible. Only implement what was asked for.
2. Do not eagerly add `#[derive(...)]` implementations like a `Debug` or `Clone`. Only add them when needed.
3. Avoid section and header comments like for example `// -- Types ---------`; use `// Types` instead if it truly makes sense.
4. Define all Rust structs, enums, etc.. first (in logical order) followed by their `impl` blocks in the same order.
```rust
// Bad
enum Foo { ... }
Expand All @@ -35,7 +41,7 @@ impl Foo { ... }
impl Bar { ... }
```

4. Group statements by logical intent, separated by blank lines. Each group should have a brief comment describing *what* it does so the function reads like an outline — readers can skim the comments top-to-bottom and only dive into the code when they need the *how*. Omit the comment only when the intent is immediately obvious from the code itself. For example
5. Group statements by logical intent, separated by blank lines. Each group should have a brief comment describing *what* it does so the function reads like an outline — readers can skim the comments top-to-bottom and only dive into the code when they need the *how*. Omit the comment only when the intent is immediately obvious from the code itself. For example
```rust
pub fn source_text(&self, span: Span) -> &str {
let file = self.lookup_source_file(span.lo());
Expand Down Expand Up @@ -63,7 +69,7 @@ pub fn lookup_line_col(&self, pos: BytePos) -> (&str, u32, u32) {
}
```

5. When snapshot testing, prefer inline snapshots. Also use `cargo insta --help` to interact with snapshot management.
6. When snapshot testing, prefer inline snapshots. Also use `cargo insta --help` to interact with snapshot management.
```rust
// Bad
insta::assert_snapshot!(result);
Expand Down
Loading