Should your Go service scaffold ban http.DefaultServeMux and ListenAndServe, and how would you enforce that?

## Separate the technical call from the organisational one The technical call is easy and you should make it quickly: **a service should never serve `http.DefaultServeMux`.** The cost of avoiding it is a single line — `mux := http.NewServeMux()` — and the cost of not avoiding it is that any package anywhere in the build, including a transitive dependency, can publish routes on your public listener from an `init` function. Asymmetric cost, silent failure, trivial fix. There is nothing to debate. Everything interesting is in the second question: **what does "ban" mean operationally, and what does it cost you to enforce?** ## Make the right thing the default, not the wrong thing forbidden A prohibition asks every engineer to remember a rule at the moment they are least interested in it. A default asks nothing: ```go func NewServer(cfg Config, h http.Handler) *http.Server { return &http.Server{Addr: cfg.Addr, Handler: h} } ``` If the scaffold's generated `main` already calls this, and the generated `routes()` already returns a mux built with `http.NewServeMux`, then the default mux is unreachable in every service that starts from the template. You have converted a policy into a shape. Nobody has to be persuaded, nobody has to be corrected in review, and a new hire who has never heard the rule complies by doing nothing. The scaffold buys something else too: the same constructor is where every server-level setting your organisation cares about lands, so the next fleet-wide change is one edit to the template rather than a campaign. ## Then decide what the rule is actually for A default only covers services that start from the template and never drift. So you still want a check — but its job is now narrow: catch drift, not teach the lesson. That reframing changes how you write it. - **Write it on the call graph, not on text.** `http.ListenAndServe` (the package function) and `http.Handle`/`http.HandleFunc` (which register on the global mux) are the smells. `srv.ListenAndServe()` is a method call on your own server value and is exactly the pattern you are promoting. A grep for `ListenAndServe` flags both. A rule with false positives on the code you are advocating is a rule engineers learn to suppress, and once they are suppressing it they suppress the true positives too. - **Scope the hard failure.** Blocking a merge is a real cost, and it is worth paying on services in the production deploy path. On a one-file internal tool, a scratch repository, or an example in documentation, the shorthand is genuinely fine, and failing those builds spends credibility you will want later. - **Give it an escape hatch with a name on it.** An annotated exemption that records who accepted the risk is better than a rule people route around silently. ## Who can overrule you, and on what This is the part that makes it a leadership question rather than a code-style one. You own the scaffold's default and the check. You do not own the outcome alone. - **The security reviewer can force your hand.** The concrete finding — a deployed service answering 200 on `/debug/pprof/`, exposing goroutine stacks, the process command line, and a CPU profile anyone can trigger — is theirs, and it outranks a stylistic preference. If they escalate, your job is to have already shipped the fix as a default so the remediation is a template bump rather than a fleet-wide code change. - **Service teams can legitimately push back on the mechanism, not the default.** "We need profiling in production" is a real requirement, and answering it with "the rule says no" is the wrong answer. Answer it by mounting `net/http/pprof`'s exported handlers on a second `http.Server` bound to an internal listener, and ship that in the scaffold too. A policy that removes a capability people need gets circumvented; one that relocates it gets adopted. ## Measure the outcome, not the compliance The check that tells you the policy worked is **an external probe of every deployed service for `/debug/pprof/` and `/debug/vars`**, run continuously. Counting pull requests that cited the rule, or confirming the template compiles, measures the process rather than the exposure. Services predate the scaffold, get vendored, get copied from a blog post; only the probe sees all of them. ## What a strong answer sounds like It takes a position (yes on the default mux, and the shorthand follows from it), converts the prohibition into a default so enforcement is cheap, narrows the lint rule so it does not cry wolf on the method call, scopes the hard failure to what is deployed, names who can overrule the decision and on what evidence, and picks an outcome measure rather than a compliance measure. Answers that stop at "ban it, it is bad practice" have solved the easy half.