sneak/prompts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: sneak:59999115b110beaf92a80d6e14c5714af7a8abfc
Branches Tags
sneak:main sneak:llm-prose-tells-v10 sneak:llm-prose-tells-merge-pass sneak:llm-prose-tells-final sneak:llm-prose-tells-checklist-pass sneak:llm-prose-tells-updates sneak:add-llm-prose-tells sneak:improve-quickstart-commands
...
compare: sneak:d83bd08d4d83253a5ebcb4ca06023d43602dc431
Branches Tags
sneak:main sneak:llm-prose-tells-v10 sneak:llm-prose-tells-merge-pass sneak:llm-prose-tells-final sneak:llm-prose-tells-checklist-pass sneak:llm-prose-tells-updates sneak:add-llm-prose-tells sneak:improve-quickstart-commands

3 Commits
59999115b1 ... d83bd08d4d

Author SHA1 Message Date
clawbot
d83bd08d4d style: fix prettier formatting in constructor naming section
All checks were successful
check / check (push) Successful in 6s
Details
2026-03-17 21:41:33 -07:00
user
4c643d1aa2 style: Params struct required even for single arguments 
Only exception: stupidly obvious single args (featureflag.New(true)).
When in doubt, use Params.
 2026-03-17 21:41:33 -07:00
user
e72b2d3522 style: strengthen constructor naming and Params struct rules 
- Constructors must be New(), From<Something>(), or NewThing() (multi-type pkg)
- Strongly discourage creative names (Create, Make, Build, Init)
- Constructors must use Params struct for 2+ arguments, no exceptions
- Single obvious argument (ctx, bytes) is the only exception
 2026-03-17 21:41:33 -07:00
1 changed files with 18 additions and 5 deletions
Expand all files Collapse all files

23
prompts/CODE_STYLEGUIDE_GO.md
View File

@@ -136,8 +136,15 @@ last_modified: 2026-02-22
1. Provide a .gitignore file that ignores at least `*.log`, `*.out`, and
`*.test` files, as well as any binaries.
1. Constructors should be called `New()` whenever possible. `modulename.New()`
works great if you name the packages properly.
1. Constructors **must** be called `New()`. `modulename.New()` works great if
you name the packages properly. If the constructor creates an instance from
an existing value or representation, `From<Something>()` (e.g.
`FromBytes()`, `FromConfig()`) is also acceptable. If the package contains
multiple types and `New()` is ambiguous, `NewThing()` is occasionally
acceptable — but prefer restructuring packages so each type gets its own
package and a plain `New()`. Do not invent creative constructor names like
`Create()`, `Make()`, `Build()`, `Open()` (unless wrapping an OS resource),
or `Init()`. If you see a constructor with a non-standard name, rename it.
1. Don't make packages too big. Break them up.
@@ -149,9 +156,15 @@ last_modified: 2026-02-22
1. Use descriptive names for modules and filenames. Avoid generic names like
`server`. `util` is banned.
1. Constructors should take a Params struct if they need more than 1-2
arguments. Positional arguments are an endless source of bugs and should be
avoided whenever possible.
1. Constructors **must** take a `Params` struct (or `ThingParams` when
`NewThing()` is used), even for a single argument. Named fields in a Params
struct are always clearer than positional arguments. Positional arguments
for constructors are an endless source of bugs — they make call sites
unreadable, invite wrong-order errors that the compiler can't catch when
types coincide, and force every caller to update when a new field is added.
The only exception is when the single argument is stupidly obvious from
context — e.g. `featureflag.New(true)` or `thing.NewFromReader(r)`. When in
doubt, use a Params struct.
1. Use `context.Context` for all functions that need it. If you don't need it,
you can pass `context.Background()`. Anything long-running should get and