go-packageslisted

# Go Packages and Imports This skill covers package organization and import management following Google's and Uber's Go style guides. --- ## Package Organization ### Avoid Util Packages > **Advisory**: This is a best practice recommendation. Package names should describe what the package provides. Avoid generic names like `util`, `helper`, `common`, or similar—they make code harder to read and cause import conflicts. ```go // Good: Meaningful package names db := spannertest.NewDatabaseFromFile(...) _, err := f.Seek(0, io.SeekStart) // Bad: Vague package names obscure meaning db := test.NewDatabaseFromFile(...) _, err := f.Seek(0, common.SeekStart) ``` Generic names like `util` can be used as *part* of a name (e.g., `stringutil`) but should not be the entire package name. ### Package Size > **Advisory**: This is best practice guidance. **When to combine packages:** - If client code likely needs two types to interact, keep them together - If types have tightly coupled implementations - If users would need to import both packages to use either meaningfully **When to split packages:** - When something is conceptually distinct - The short package name + exported type creates a meaningful identifier: `bytes.Buffer`, `ring.New` **File organization:** No "one type, one file" convention in Go. Files should be focused enough to know which file contains something and small enough to find things easily. --- ## Imports ### Import Organization > **Normative**: This is r