Code Formatting

代码质量、格式与约定

代码格式与 Lint 检查

• 编写 Go 代码后使用 make lint-fix，自动修复大多数 Lint 问题
• 提交前运行 make verify，确认 Lint 检查和测试均通过
• 对于 Markdown 文件，使用 make verify-codespell 检查拼写错误

测试约定 - 强制要求

测试命名

不可妥协的规则：每个 Go 测试名称都必须遵循以下格式：

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

示例：

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"

绝不要使用以下通用名称：

• ❌「没有托管标识的常规情况」
• ❌「包含 ImageID 的基本 Azure 机器模板」
• ❌「错误情况 - 子网 ID 无效」

始终使用“When...it should...”格式：

• ✅「当 NodePool 没有托管标识时，应创建不带标识的模板」
• ✅「当 NodePool 有 ImageID 时，应创建基本 Azure 机器模板」
• ✅「当子网 ID 无效时，应返回包含子网解析消息的错误」

单元测试函数命名

单元测试函数必须以其测试的函数命名，并遵循标准 Go Test<FunctionName> 约定：

// Testing function ReconcileNodePool
func TestReconcileNodePool(t *testing.T) { ... }

// Testing function buildAzureMachineTemplate
func TestBuildAzureMachineTemplate(t *testing.T) { ... }

绝不要使用通用或不对应的测试函数名称，例如：

• ❌ TestNodePoolFeatures
• ❌ TestAzureIntegration
• ❌ TestVariousCases

每个测试函数都应与被测函数一一对应。如果某个函数足够复杂，需要许多测试用例，请在单个 Test<FunctionName> 函数中使用表驱动测试，并为每个用例采用“When...it should...”命名格式。

单元测试位置

• 创建新函数或修改现有函数时，始终添加单元测试
• 将单元测试放在被测代码旁边——位于同一包目录中的 _test.go 文件内
• 不要将新测试放在 test/integration/ 中——这是一个旧目录。新的单元测试应与被测代码放在一起。需要集群的新集成式测试应使用 test/e2e/ 或 test/envtest/

快速检查清单

提交前：

• 已对 Go 代码运行 make lint-fix
• 已运行 make verify（通过）
• 测试采用“When...it should...”命名格式
• 新函数有单元测试
• 已使用 make verify-codespell 检查 Markdown