azure-sdk-for-go: Instructions file for GitHub Copilot

All code should follow the guidelines from the Azure Go SDK Guidelines. This document is a summary of the most important guidelines to follow when contributing to the Azure Go SDK.

Some additional rules:

• Acronyms are fully uppercased in every identifier a customer can see: exported types, structs, fields, functions, methods, and constants (for instance, 'id' in UserID, or 'acs' in ACSRecordedEvent), plus function and method parameter names, which appear in the published signature and godoc (userID, not userId). Casing on parameters isn't API surface, so treat it as a low-priority nit — but don't skip it, since inconsistency spreads by copy-paste. This rule does not apply to function/method locals, which customers never see, nor to string constant values.
• All Go files should have a copyright header. The header might be after go build directives, like "//go:build go1.18"

Generated Code — DO NOT suggest changes to any of the patterns below

Generated code is identified by the header comment // Code generated by Microsoft (R) Go Code Generator.. Do not suggest any modifications to files that contain this header unless there is a clear bug that is NOT covered by the rules below. Every pattern listed here is intentional and by design.

1. reflect.ValueOf(v).IsNil() without a kind guard is safe. All model/struct properties are generated as pointer types (*string, *int32, etc.), so IsNil() will never be called on a non-nilable kind. Do not suggest adding a kind check.

2. strings.Index(method, ".") without a -1 guard is safe. All operation names follow the pattern XxxClient.OperationName — the dot is always present. Do not suggest adding an index check for -1.

3. LRO initial-response status codes intentionally omit 200 OK. The initial HTTP response for a long-running operation never returns 200; only subsequent polling requests do. The fake server's 200 handler exists for polling, not for the initial call. Do not suggest adding http.StatusOK to the initial-response HasStatusCode check.

4. Doc comments and links are copied verbatim from the API specification. Even when a comment appears incorrect, misleading, or inconsistent (e.g., a response comment mentioning the wrong type), it must not be changed in the SDK. Fixes belong in the upstream spec repo (azure-rest-api-specs). Do not suggest edits to these comments or links.

5. Example values are copied verbatim from the API specification. Placeholder GUIDs, resource names, property values, and enum-like strings in generated example tests come directly from the spec's example definitions. Do not suggest changing them for consistency, style, or enum correctness.

6. moduleName intentionally omits the major-version suffix. For example, the constant is "github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/foo/armfoo" even when the module path is .../armfoo/v2. This is by design. Do not suggest appending the version suffix.

7. Constant values are defined by the service team. Enum members, endpoint-type strings, and other constants are generated exactly as declared in the API spec. Do not suggest changing a constant's value for consistency or style.

   Exception — acronym casing of the identifier. Go uppercases acronyms in exported identifiers (S3WithHMAC, UserID) while most other languages do not, so these are frequently missed in the spec. Casing violations are worth flagging even in generated code, for enum and constant member names and for function parameters (userID, not userId) alike. Parameters aren't public surface, but leaving them inconsistent looks sloppy; raise those as a low-priority nit. The fix belongs upstream in azure-rest-api-specs via a client-name customization (e.g. @clientName); never suggest editing the generated file directly, since it will be overwritten. This covers the identifier only, not the string value: renaming S3WithHmac to S3WithHMAC is in scope, changing its "S3WithHmac" wire value is not.