From f9dcef4c9e8ebdbd060da13762c95b106fd98768 Mon Sep 17 00:00:00 2001 From: user Date: Mon, 23 Feb 2026 11:47:50 -0800 Subject: [PATCH 1/2] style(go): add rule against type-only packages Types should live alongside their implementations, not in separate 'types', 'domain', or 'models' packages. Type-only packages cause alias imports and indicate poor package design. Prompted by review feedback on upaas PR #126. --- prompts/CODE_STYLEGUIDE_GO.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/prompts/CODE_STYLEGUIDE_GO.md b/prompts/CODE_STYLEGUIDE_GO.md index f859589..60a725c 100644 --- a/prompts/CODE_STYLEGUIDE_GO.md +++ b/prompts/CODE_STYLEGUIDE_GO.md @@ -229,6 +229,15 @@ last_modified: 2026-02-22 1. Define your struct types near their constructors. +1. Do not create packages whose sole purpose is to hold type definitions. + Packages named `types`, `domain`, or `models` that contain only structs and + interfaces (with no behavior) are a code smell. Define types alongside the + code that uses them. Type-only packages force consuming packages into alias + imports and circular-dependency gymnastics, and indicate that the package + boundaries were drawn around nouns instead of responsibilities. If multiple + packages need the same type, put it in the package that owns the behavior, + or in a small, focused interface package — not in a grab-bag types package. + 1. Define your interface types near the functions that use them, or if you have multiple conformant types, put the interface(s) in their own file. -- 2.45.2 From 7676ec16c3e3ef3c9f7192445db30389f24d99b7 Mon Sep 17 00:00:00 2001 From: user Date: Mon, 23 Feb 2026 11:56:16 -0800 Subject: [PATCH 2/2] style(go): add Stringer rule for custom string-based types --- prompts/CODE_STYLEGUIDE_GO.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/prompts/CODE_STYLEGUIDE_GO.md b/prompts/CODE_STYLEGUIDE_GO.md index 60a725c..0af4d3c 100644 --- a/prompts/CODE_STYLEGUIDE_GO.md +++ b/prompts/CODE_STYLEGUIDE_GO.md @@ -238,6 +238,20 @@ last_modified: 2026-02-22 packages need the same type, put it in the package that owns the behavior, or in a small, focused interface package — not in a grab-bag types package. +1. When defining custom string-based types (e.g. `type ImageID string`), + implement `fmt.Stringer`. Use `.String()` at SDK and library boundaries + instead of `string(v)`. This makes type conversions explicit, grep-able, + and consistent across the codebase. Example: + + ```go + type ContainerID string + + func (id ContainerID) String() string { return string(id) } + + // At the Docker SDK boundary: + resp, err := c.docker.ContainerStart(ctx, id.String(), opts) + ``` + 1. Define your interface types near the functions that use them, or if you have multiple conformant types, put the interface(s) in their own file. -- 2.45.2