r/golang

Just give it a try. Its one less error you'll have to worry about.

Tried it on my app, I don't get any errors, nor anything for that matter.

Here is an excellent talk from Konrad Reiche, an engineer at Reddit, during GoLab 2025

Summary:

1. Handle Errors

• Avoid silently discarding errors (e.g., using the blank identifier _).

• Avoid swallowing the error.

• When handling errors, you should Check and Handle the Error (e.g., incrementing a failure counter or logging).

• Avoid Double Reporting: Log the error, or return it—but not both.

• Optimize for the Caller:

  • return result, nil is Good: The result is valid and safe to use.

  • return nil, err is Good: The result is invalid; handle the error.

  • return nil, nil is Bad: This is an ambiguous case that forces extra nil checks.

  • return result, err is Bad/Unclear: It is unclear which value the caller should trust.

2. Adding Interfaces Too Soon

• Interfaces are commonly misused due to Premature Abstraction (often introduced by following object-oriented patterns from languages like Java) or solely to Support Testing. Relying heavily on mocking dependencies for testing can weaken the expressiveness of types and reduce readability.

• Don't Start With Interfaces:

  • Follow the convention: accept interfaces, return concrete types.

  • Begin with a concrete type. Only introduce interfaces when you truly need multiple interchangeable types.

  • Litmus Test: If you can write it without, you probably don’t need an interface.

• Don't Create Interfaces Solely for Testing: Prefer testing with real implementations.

3. Mutexes Before Channels

• Channels can introduce complex risks, such as panicking when closing a closed channel or sending on a closed channel, or causing deadlocks.

• Start Simple, Advance One Step At a Time:

  • Begin with synchronous code.

  • Only add goroutines when profiling shows a bottleneck.

  • Use sync.Mutex and sync.WaitGroup for managing shared state.

  • Channels shine for complex orchestration, not basic synchronization.

4. Declare Close to Usage

• This is a Universal Pattern that applies to constants, variables, functions, and types.

• Declare identifiers in the file that needs them. Export identifiers only when they are needed outside of the package.

• Within a function, declare variables as close as possible to where they will be consumed.

• Limit Assignment Scope: Smaller scope reduces subtle bugs like shadowing and makes refactoring easier.

5. Avoid Runtime Panics

• The primary defense is to Check Your Inputs. You must validate data that originates from outside sources (like requests or external stores).

• Avoid littering the code with endless $if x == nil$ checks if you control the flow and trust Go’s error handling.

• Always Check Nil Before Dereferencing.

• The best pointer safety is to Design for Pointer Safety by eliminating the need to explicitly dereference (e.g., using value types in structs instead of pointers).

6. Minimize Indentation

• Avoid wrapping all logic inside conditional blocks (BAD style).

• Prefer the Good: Return Early, Flatter Structure style by handling errors or negative conditions first.

7. Avoid Catch-All Packages and Files

• Avoid generic names like util.go, misc.go, or constants.go.

• Prefer Locality over Hierarchy:

  • Code is easier to understand when it is near what it affects.

  • Be specific: name packages after their domain or functionality.

  • Group components by meaning, not by type.

8. Order Declarations by Importance

• In Go, declaration order still matters greatly for readability.

• Most Important Code to the Top:

  • Place exported, API-facing functions first.

  • Follow these with helper functions, which are implementation details.

  • Order functions by importance, not by dependency, so readers see the entry points upfront.

9. Name Well

• Avoid Type Suffixes (e.g., userMap, idStr, injectFn). Variable names should describe their contents, not their type.

• The Variable Length should correspond to its scope: the bigger the scope of a variable, the less likely it should have a short or cryptic name.

10. Document the Why, Not the What

• Justify the Code's Existence.

• When writing comments, communicate purpose, not merely restate the code.

• Document the intent, not the mechanics.

• Future readers need to understand the motivation behind your choices, as readers can usually see what the code does, but often struggle to understand why it was written in the first place.