When to use a method (owns the data, needs state, is the domain question), when to use a function (operates across types, is a utility, was incorrectly coupled), and when to move code in both directions. Go gives you two ways to attach behavior to logic: methods (with a receiver) and functions (without). Most languages make this decision for you — if it touches a class, it's a method. In Go, you have to choose. The wrong choice shows up as code issues: a free function that takes a type as its first argument (should be a method), a method that doesn't use its receiver (should be a function), or a method on the wrong type (should be on the type it operates on). Here are 6 decision criteria, each with a real before/after refactoring that moved code in the right direction — including two cases where methods became functions. 1.…