Code Quality

Dependency inversion is a fundamental principle in software design that enhances code cleanliness, maintainability, and extensibility. While not exclusive to Go, the way it manifests in this language is particularly accessible and effective. At its heart, dependency inversion asserts that high-level components should not rely directly on low-level modules. Instead, both should depend on abstractions, fostering a more adaptable architecture. In practical Go development, this means crafting your business logic to interface with small abstractions that express what functionality is needed rather than focusing on how that functionality is implemented. This post dives into how to leverage this principle in Go, highlighting potential pitfalls and offering concrete examples to demonstrate correct implementation. ...

When designing Go APIs, you might think it’s harmless to return (nil, nil) when an object isn’t found. Many developers do this because it feels like “not found” shouldn’t be treated as an error. However, this approach often leads to one of the most frustrating runtime crashes in Go: panic: invalid memory address or nil pointer dereference In this post, we’ll cover: The problem — how (nil, nil) breeds fragile code Why this design creates real-world headaches Two solutions: Best practice (recommended): return a predefined error instead Alternative pattern: use an explicit existence flag An evolved, safer version of the code The goal isn’t just to fix mistakes, but to enhance API design to prevent misuse down the line. ...

Introduction For many Go developers, a recurring challenge has been: “What is the right way to handle multiple errors?” Whether it’s running several cleanup steps, processing batches of data, or validating various inputs, ensuring errors are handled correctly and efficiently has been crucial. Before Go 1.20, developers did not have a unified approach; each team created its own solution, often leading to awkward, unidiomatic, or even incorrect patterns. With Go 1.20, we now have a standard, pragmatic solution: errors.Join. This article will explore why older techniques were problematic, how the Go team designed a better approach, and how to apply this new solution effectively in your code. ...