Qualité du code, formatage et conventions

Formatage du code et linting

• Utilisez make lint-fix après avoir écrit du code Go pour corriger automatiquement la plupart des problèmes de linting
• Exécutez make verify pour vérifier que le linting et les tests passent avant de committer
• Pour les fichiers markdown, utilisez make verify-codespell pour détecter les erreurs d'orthographe

Conventions de test - OBLIGATOIRE

RÈGLE NON-NÉGOCIABLE : Tout nom de test Go DOIT suivre ce format exact :

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

Exemples :

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"

NE JAMAIS utiliser de noms génériques comme :

• ❌ "nominal case without managed identity"
• ❌ "basic Azure machine template with ImageID"
• ❌ "error case - invalid subnet ID"

TOUJOURS utiliser le format « When...it should... » :

• ✅ "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"

• Incluez toujours des tests unitaires lors de la création de nouvelles fonctions ou de la modification de fonctions existantes

Liste de vérification rapide

Avant de committer :

• [ ] Exécuté make lint-fix sur le code Go
• [ ] Exécuté make verify (réussi)
• [ ] Les tests utilisent le format de nommage « When...it should... »
• [ ] Les nouvelles fonctions ont des tests unitaires
• [ ] Markdown vérifiée avec make verify-codespell