Our Go style is not merely about formatting code—it’s our design philosophy. It blends engineering excellence with artful clarity to ensure that our systems are safe, high-performance, and enjoyable to develop and maintain.
In our view, design is as much about how the system works as what it looks like. Our style makes each decision explicit, ensuring that safety, performance, and developer experience remain paramount.
- **Simplicity** is our ultimate goal—but it is never a free pass. Achieving simplicity is the result of thoughtful design and disciplined iteration.
- A “zero technical debt” policy applies: we design and implement things right the first time. This saves each of us from the cost of firefighting production issues later.
Even in Go, safety is non‐negotiable. We frequently embed explicit checks and assertions to ensure our code behaves as expected. Consider this sample assertion helper:
- Use **simple, explicit control flow** (avoid unnecessary recursion and hidden complex abstractions).
- **Limit loops and queues**: every loop should have an explicit upper bound to avoid infinite cycles.
- Favor fixed-size types (e.g., use `uint32` or `int32` where appropriate) instead of architecture-dependent sizes.
- Use assertions liberally—both to check expected states _before_ and _after_ important operations. Aim for at least two assertions per function.
- All memory usage should be planned up-front. Although Go provides garbage collection, design your modules with a fixed resource strategy in mind for predictability.
- Keep function bodies short. In Go, we suggest striving for functions to be easily digestible (roughly keeping functions around 70 lines or less) by breaking out helper functions where it makes sense.
- Identify the slowest resource (network → disk → memory → CPU) and optimize that first.
- Use batching to reduce overhead and context switching. For example, aggregate database writes rather than doing them one at a time.
- Separate the control plane from the data plane. For “hot loops” or performance‐critical code, create small, stateless helper functions accepting primitive types. This helps both the compiler and human reviewers spot redundant computations.
- **Go idioms:** For exported functions, use `CamelCase` (e.g., `ReadSector`), and for local functions and variables, use `camelCase`.
- Avoid abbreviations unless they are well-known acronyms (for example, use `HTTPStatus` rather than `httpStatus`).
- Include units and qualifiers in variable names at the end, so names like `latencyMsMax` (where “Ms” stands for milliseconds) are both clear and neatly aligned with related variables.
- When a function delegates work to helpers, consider prefixing the helper name with the parent function (e.g., `readSectorCallback`) to provide context.
- Place important constructs (like `main`) or critical types near the top of files for clarity.
In our adapted TigerStyle for Go, every detail—from strict assertions to deliberate naming and error handling—is designed to create robust, clear, and high-performance software. Remember: even though some of these practices (like assertions) aren’t common in Go, we include them as an essential part of our commitment to safety and clarity.
