Summary
The Azure SDK for .NET Mgmt SDK has a documented set of naming conventions. Today these conventions are enforced after the SDK is generated, via @@clientName(..., "csharp") decorators added during SDK review in the TypeSpec spec. This is reactive and error-prone — names that don't follow the conventions can slip through whenever a reviewer misses them.
We should enforce these rules on the spec side via TypeSpec linters (TCGC / typespec-azure-resource-manager rules) so that:
- Authors get immediate, actionable feedback while writing the spec.
- Generated SDKs are .NET-convention-compliant by default.
- The need for hand-authored
@@clientName(..., "csharp") overrides drops dramatically.
This is the parent issue tracking a family of linter rules, one per naming convention. Each sub-issue below covers one specific rule.
Summary
The Azure SDK for .NET Mgmt SDK has a documented set of naming conventions. Today these conventions are enforced after the SDK is generated, via
@@clientName(..., "csharp")decorators added during SDK review in the TypeSpec spec. This is reactive and error-prone — names that don't follow the conventions can slip through whenever a reviewer misses them.We should enforce these rules on the spec side via TypeSpec linters (TCGC / typespec-azure-resource-manager rules) so that:
@@clientName(..., "csharp")overrides drops dramatically.This is the parent issue tracking a family of linter rules, one per naming convention. Each sub-issue below covers one specific rule.