---
applyTo: '**/*.go'
---

All code should follow the guidelines from the [Azure Go SDK Guidelines](https://azure.github.io/azure-sdk/golang_introduction.html). 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.
