Code style conventions for altium-designer-mcp.
Single source of truth: see the documentation registry in CONTRIBUTING.md § Single Source of Truth for the canonical location of each kind of information.
| Rule | Setting |
|---|---|
| Indentation | 4 spaces (no tabs) |
| Max line length | 170 characters |
| Charset | UTF-8 |
| Final newline | Always |
| Trailing whitespace | Trim (except Markdown) |
These rules are enforced by .editorconfig. Install the EditorConfig plugin for your editor:
- VS Code: EditorConfig for VS Code
VS Code also displays a ruler at 170 characters (configured in .vscode/settings.json).
Use British English in all documentation and user-facing text.
See CONTRIBUTING.md § British Spelling for the full spelling guide.
Exceptions:
- Code identifiers matching Rust/library conventions (e.g.,
Colorin external APIs) - Protocol-defined terms (e.g.,
initializein MCP specification) - Standard file names (e.g.,
LICENSEif required by tooling) - External legal documents (e.g., GPL licence text)
Standard Rust conventions, enforced by CI:
- Formatting:
rustfmtwith default settings. - Linting:
clippywith warnings as errors.
The exact commands are canonical in CONTRIBUTING.md § Development Setup — this guide does not repeat them.
| Item | Convention | Example |
|---|---|---|
| Crates | snake_case | altium_designer_mcp |
| Modules | snake_case | pcblib |
| Types | PascalCase | Footprint |
| Functions | snake_case | write_pcblib |
| Constants | SCREAMING_SNAKE_CASE | DEFAULT_LINE_WIDTH |
| Variables | snake_case | pad_width |
- All public items must have doc comments (
///) - CI checks documentation builds without warnings
The repository ships git-tracked Python helper scripts under scripts/ and the MCP integration harness under
tests/integration/. Follow these conventions:
- Follow PEP 8.
- 4-space indentation (no tabs) — aligned with the project-wide convention.
- Use
snake_casefor functions and variables,PascalCasefor classes,SCREAMING_SNAKE_CASEfor constants. - Add a module-level docstring describing what each script does.
- Prefer the standard library; keep helper scripts dependency-free so they run without a virtual environment.
4 spaces for structure levels — aligned with project-wide convention.
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build
run: cargo buildList items use 2-space continuation from the - character (standard YAML behaviour):
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "daily"Shell script content inside run: | blocks uses 4-space indentation for shell constructs (if/else, loops):
- name: Example step
shell: bash
run: |
if [[ -n "$VAR" ]]; then
echo "Variable is set"
else
echo "Variable is not set"
fiFormat-on-save is disabled for YAML files in VS Code (configured in .vscode/settings.json).
4 spaces.
{
"key": "value",
"nested": {
"item": 123
}
}VS Code uses the built-in JSON formatter (vscode.json-language-features).
4 spaces.
[package]
name = "altium-designer-mcp"
version = "0.1.0"
[dependencies]
serde = { version = "1.0", features = ["derive"] }Use Even Better TOML for VS Code.
Column width is set to 170 characters (configured in .vscode/settings.json).
Use ATX-style headings with blank lines before and after:
## Section Title
Content here.Use - for unordered lists, 1. for ordered lists.
Always specify the language:
```rust
fn main() {
println!("Hello!");
}
```Markdown files are exempt from trailing whitespace trimming (needed for line breaks).
See CONTRIBUTING.md § Commit Messages for conventions and allowed types.
- All dimensions in millimetres (mm)
- Use
f64for dimensional values - Document units in variable names or comments when not obvious
- For the complete primitive types reference, see
README.md§ Primitive Types
Last updated: 2026-01-24