Go Code Quality & Maintainability on Atharva Pandey

Lesson 8: Linting with golangci-lint — Automate what reviewers shouldn''t waste time on

Sun, 01 Jun 2025 00:00:00 +0000

I made a rule for myself a few years ago: if I leave a code review comment about something a tool could have caught, I’ve wasted both the author’s time and mine. A linter can catch unused variables, missing error checks, shadowed variables, inefficient string concatenation, and dozens of other patterns automatically — in seconds, every commit, without reviewer fatigue. The code review should be about design and correctness, not about whether someone forgot to handle an error returned by rows.Close().

Lesson 7: Kill the Utils Package — util.go is where code goes to hide

Tue, 01 Apr 2025 00:00:00 +0000

Every Go codebase I’ve worked on for more than a year has a util package. Some have a helpers package. Some have both. I’ve seen common, shared, misc, and once, memorably, stuff. These packages are where code goes when a developer doesn’t know where it belongs — which means they’re the first place reviewers stop reading carefully, the last place new engineers look when they can’t find something, and the primary location of dead code in any codebase over 18 months old.

Lesson 6: Package Cohesion — Everything in a package should belong together

Thu, 06 Feb 2025 00:00:00 +0000

Go packages are the primary unit of code organization. They determine what’s visible to whom, what gets compiled together, and — most importantly — they communicate intent to every engineer who reads the codebase. A package with high cohesion says something true and useful: “everything here is about orders” or “everything here handles HTTP middleware.” A package with low cohesion says nothing — it’s a filing cabinet where things went when nobody knew where else to put them.

Lesson 5: Small Functions Win — If you can''t name it clearly, it does too much

Fri, 06 Dec 2024 00:00:00 +0000

There is a simple test I apply to any function I’m about to merge: can I name it clearly without using “and”? If the most honest name for a function is validateAndSaveAndNotifyUser, the function is three functions pretending to be one. The naming test doesn’t lie — it’s a direct readout of the function’s responsibility. I’ve seen this test convince engineers who were unmoved by SOLID principles or Uncle Bob quotes, because it’s visceral: if you can’t say what the function does in a few words, you already know something is wrong.

Lesson 4: Code Review Heuristics — What to look for in a Go PR

Sun, 20 Oct 2024 00:00:00 +0000

A good code review is not a diff-reading exercise. It’s a transfer of understanding — the reviewer asks “do I understand what this code does, why it does it, and what it doesn’t do?” If the answer to any of those is no, that’s a comment, not a nitpick. I’ve done hundreds of Go reviews and the feedback I give clusters into the same ten or fifteen patterns so reliably that I eventually wrote them down as a checklist. This lesson is that checklist, with examples.

Lesson 3: Idiomatic Naming — Names are your documentation

Wed, 04 Sep 2024 00:00:00 +0000

When I review Go code, naming problems tell me more about the author’s understanding of the codebase than almost anything else. A function called HandleRequest that parses JSON, queries a database, formats a response, and writes to a log tells me its author didn’t know what it does either. A variable called data in a function that handles three different kinds of data tells me the author stopped thinking halfway through. Names are the first layer of documentation — they’re read far more often than comments, and unlike comments, they can’t drift out of sync with the code.

Lesson 2: Spotting Over-Abstraction — When your abstraction is the problem

Wed, 24 Jul 2024 00:00:00 +0000

There’s a version of Go code I see in almost every codebase that’s been touched by developers who came from Java or C# — it’s covered in interfaces, repositories, factories, and service layers that all wrap exactly one concrete implementation. No tests mock these interfaces. No second implementation exists. The abstraction is doing nothing except adding indirection. I’ve written code like this myself, and the tell is always the same: when something breaks, I have to jump through five files to understand what happens when I call CreateUser.

Lesson 1: Refactoring Go Code Safely — Change structure without changing behavior

Sun, 16 Jun 2024 00:00:00 +0000

Refactoring is the one activity that makes codebases better without adding features — and it’s also the activity most likely to introduce bugs if done carelessly. I learned this the hard way on a payments service where I renamed a function, ran the tests, saw green, deployed, and watched a webhook handler silently stop processing because it had been calling the old function name through a string-based registry I hadn’t touched. The tests were green because the old function still existed — I just hadn’t deleted it yet. The refactor was correct; the process was not.