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