evilissimo/naming-things
Reviews and improves **names** in code — variables, functions, classes, modules, parameters — for clarity, intent, and consistency with language/team conventions. Triggers when asked to review names, rename things, improve code readability, clean up confusing code, or when examining code with generic/vague names like "data", "info", "manager", "temp", "util". Does NOT trigger for general code review unrelated to naming, architecture design, debugging, or performance optimization. Identifies naming anti-patterns (generic names, misleading names, type-encoding, abbreviations), suggests role-based names that reveal intent, checks consistency with project/domain vocabulary, and flags misalignment with language culture.
91
90%
Does it follow best practices?
Impact
94%
1.05xAverage score across 5 eval scenarios
Passed
No known issues
task.mdevals/scenario-3/
Go Package API Rename Plan
Problem/Feature Description
A Go service has a small package used by several teams to parse allowlist strings from environment variables. The package has become a dumping ground, and its exported API is hard to read in callers. The team wants a naming-focused plan and a revised version that follows Go conventions.
Review the snippet and propose better package, function, receiver/interface, and local names. Preserve behavior and explain any compatibility concerns for exported names.
Output Specification
Produce go_naming_review.md with old/new names and rationale. Produce allowlist.go with the revised code.
Input Files
=============== FILE: util.go ===============
package util
import "strings"
type IData interface {
GetData(s string) ([]string, error)
}
type DataManager struct{}
func (this *DataManager) GetData(s string) ([]string, error) {
var res []string
for _, item := range strings.Split(s, ",") {
str := strings.TrimSpace(item)
if str != "" {
res = append(res, str)
}
}
return res, nil
}
func Run(flag bool, s string) []string {
d := &DataManager{}
out, _ := d.GetData(s)
if flag {
return out
}
return nil
}