azure-sdk-for-go go-code.instructions.md

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 in exported type/struct/function names (for instance, 'id' in UserID, or 'acs' in ACSRecordedEvent) should be uppercased. This rule does not apply to string constants.
• 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 and their casing are defined by the service team. Enum members, endpoint-type strings, and other constants are generated exactly as declared in the API spec. Even if the casing appears to violate the repo's acronym convention (e.g., S3WithHmac instead of S3WithHMAC), they must not be renamed. Do not suggest casing changes for generated constants.

8. Some path parameters are intentionally unescaped. Parameters such as resourceUri represent multi-segment ARM resource IDs that contain slashes. They are inserted with strings.ReplaceAll instead of url.PathEscape on purpose. Do not suggest adding URL escaping for these parameters.