Linter: enforce two-letter acronym casing (`Db`→`DB`, `Ip`→`IP`, `Os`→`OS`, …) with `Vm`/`Id` exceptions

[haiyuazhang]

Parent: #4442

Convention

Two-letter acronyms should be all-uppercase when not part of longer compound identifiers, with exceptions like Vm, Id.

Source: Azure SDK for .NET Mgmt Naming Conventions

Observed today

A scan of Azure/azure-rest-api-specs (334 client.tsp files, 10,754 csharp-scoped @@clientName decorators) shows 221 decorators currently encoding this rule by hand. Examples:

• VirtualMachineScaleSetIpTag → ComputeFleetVmssIPTag (azurefleet/resource-manager/Microsoft.AzureFleet/AzureFleet/client.tsp)
• IpAddress → LargeInstanceIPAddress (azurelargeinstance/resource-manager/Microsoft.AzureLargeInstance/AzureLargeInstance/client.tsp)
• cosmosDbResourceId → cosmosDBResourceId (agricultureplatform/AgriculturePlatform.Management/client.tsp)
• CosmosDb → CosmosDB (billingbenefits/BillingBenefits.Management/client.tsp)
• OsProfile → LargeInstanceOSProfile (azurelargeinstance/resource-manager/Microsoft.AzureLargeInstance/AzureLargeInstance/client.tsp)
• HciOsProfile → HciOSProfile (azurestackhci/resource-manager/Microsoft.AzureStackHCI/StackHCI/client.tsp)

Proposed linter

Detection

Walk all model / property / parameter / enum names. Flag any segment matching the acronym dictionary (Db, Ip, Os, Sql, Url, Uri, Tls, Ssl, Cpu, Gpu, Dns, Tcp, Udp, Sas, Aks, Acl, Api, Http, Https, Xml, Json, ...) where the canonical .NET casing is fully upper. Honor exceptions: Vm, Id.

Auto-fix

Insert @@clientName(..., "csharp") with the corrected acronym casing.

Scope

The rule should be csharp-scoped — it only flags violations of the .NET convention, not the underlying TypeSpec name. It should suggest inserting a @@clientName(..., "csharp") override when the underlying TypeSpec name is intentional, or renaming the TypeSpec model when the convention applies cross-language.

Acceptance criteria

• New lint rule registered in the appropriate ruleset (@azure-tools/typespec-client-generator-core or @azure-tools/typespec-azure-resource-manager).
• Doc page under website/src/content/docs/docs/libraries/.../rules/.
• Unit tests covering positive / negative cases and the auto-fix.
• A .chronus/changes/ entry.

[haiyuazhang]

Impact analysis: Two-letter acronym casing

Findings

Model definitions containing mis-cased two-letter acronyms:

Acronym	Model definitions
Ip (should be IP)	1,075
Os (should be OS)	809
Sql (should be SQL)	470
Db (should be DB)	459
Uri (should be URI)	393
Dns (should be DNS)	95
Url (should be URL)	77
Ssl (should be SSL)	33
Tls (should be TLS)	25
Tcp (should be TCP)	11
Udp (should be UDP)	11
Gpu (should be GPU)	8
Cpu (should be CPU)	6
Total	~3,472

• 221 existing @@clientName renames (6% adoption)
• The counts above are model definitions containing the acronym, not just the acronym itself — many models have the acronym in the middle of a compound name (e.g., IpAddress, SqlDatabase, OsProfile)

Recommendation: Not a good candidate for implementation now

~3,472 model definitions would be flagged — the largest blast radius of any proposed rule. Many of these are false positives where the casing is intentional in the TypeSpec source and only needs to differ in the C# SDK. The volume would overwhelm spec owners with warnings.