---
name: go-code-style
description: "Standard Go code style and formatting guidelines based on gofmt and Effective Go."
language: go
---

# Go Code Style

Standardized formatting and style guidelines for Go, following the language's "one way to do it" philosophy.

## Guidelines
- **Follow `gofmt`**: Use the standard formatting provided by the language. No exceptions.
- **Naming Conventions**:
  - `camelCase` for private variables and functions.
  - `PascalCase` for exported variables, functions, and types.
  - Keep names short but descriptive. Use common abbreviations (e.g., `ctx` for `context.Context`).
  - Acronyms should be all caps (e.g., `ServeHTTP`, `APIKey`, not `ApiKey`).
- **Package Organization**:
  - Name packages after what they provide, not what they contain (e.g., `net/http`, not `http_utils`).
  - Avoid `util`, `common`, or `base` package names.
- **Commentary**:
  - Every exported name should have a doc comment.
  - Comments should be complete sentences starting with the name being documented.
- **Import Grouping**: Group imports into three sections: standard library, third-party, and local, separated by blank lines. Use `goimports` to automate this.

## Tools & Libraries
- **gofmt / gofmt -s**: The official Go formatter.
- **goimports**: Automatically fixes imports and formats code.
- **golangci-lint**: For enforcing style rules.
- **gopls**: The Go language server for IDE support.

## Trigger Scenarios
- When starting a new Go project or package.
- When formatting code before a commit.
- When reviewing code for naming consistency and exported documentation.
- When a developer asks about Go naming conventions or package structure.

<!-- synapsis-dsai-managed -->
