Code Quality, Formatting and Conventions

Code Formatting and Linting

• Use make lint-fix after writing Go code to automatically fix most linting issues
• Run make verify to verify both linting and tests pass before committing
• For markdown files, use make verify-codespell to catch spelling errors

Test Conventions – MANDATORY

NON-NEGOTIABLE RULE: Every Go test name MUST follow this exact format:

name: "When <condition>, it should <expected behavior>"

Examples:

name: "When NodePool has valid image ID, it should create Azure machine template"
name: "When subnet ID is invalid, it should return error"
name: "When encryption is enabled, it should configure disk encryption set"

NEVER use generic names like:

• ❌ “nominal case without managed identity”
• ❌ “basic Azure machine template with ImageID”
• ❌ “error case – invalid subnet ID”

ALWAYS use “When…it should…” format:

• ✅ “When NodePool has no managed identity, it should create template without identity”

• ✅ “When NodePool has ImageID, it should create basic Azure machine template”

• ✅ “When subnet ID is invalid, it should return error with subnet parse message”

• Always include unit tests when creating new functions or modifying existing ones

Quick Checklist

Before committing:

• Ran make lint-fix on Go code
• Ran make verify (passes)
• Tests use “When…it should…” naming format
• New functions have unit tests
• Markdown checked with make verify-codespell