Best Practices

If you’ve been working with Go for a while and find your code resembling a plate of spaghetti, rest assured you’re not alone. This is a common challenge many developers encounter over time. The issue often isn’t a lack of design patterns or frameworks, but rather the misuse of abstractions at the wrong moments. Writing elegant Go code is about increasing readability, not demonstrating cleverness. This post outlines essential principles to transform complicated and tangled Go code into a cleaner and more maintainable form—without drifting into complex “enterprise abstraction soups.” ...

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. ...