Avoid Public Functions Calling Other Public Functions

Avoid Public Functions Calling Other Public Functions Oct 29, 2026 A small-scale rule of thumb. This article will land much better with a concrete example, but I am drawing a blank here, so you gotta just blindly trust my say so! When implementing a software module, it’s often a case that you are writing a public function foo, and at least part of what foo does is already handled by another public function bar. The DRY instinct encourages you to call bar() from within foo. This usually creates problems down the line. Instead, create a new private function and refactor both foo and bar to call that shared helper: // BAD pub fn foo() void { return bar(.{ .frobnicate = true }); } pub fn bar(options: struct { frobnicate: bool = false, }) void { // ... } // GOOD pub fn foo() void { return helper(.frobnicate); } pub fn bar() void { return helper(.transmogrify); } fn helper(mode: enum { frobnicate, transmogrify }) void { // ... } Rationale: the goal of a public API is to provide an interface…