golang-code-style

Go code readability improves by applying human-judgment rules like semantic line breaking, intent-revealing `var` vs `:=` declarations, and early returns to clarify control flow. These conventions enforce clarity that standard formatters and linters cannot capture.

Use `var` vs `:=` in Go declarations to signal intent: use `var` when declaring zero-value variables to make the zero value explicit, and use `:=` when assigning non-zero values. This intent-revealing pattern helps reviewers understand initialization expectations.

Initializing slices and maps in Go instead of leaving them nil avoids nil collection panics and clarifies intent. Non-nil initialization ensures safe operations on collections, reducing maintainability risk and preventing unexpected behavior during read or write operations.

The best way to structure Go control flow for code review is using early returns, avoiding `else` after returns, extracting complex conditions into named booleans, and using `switch` over repeated if-else comparisons to make logic clear and maintainable.

Decide between value and pointer parameters in Go functions by applying correctness heuristics: use value parameters for small, immutable data to prevent unintended mutation, and use pointers for large structs or when mutation is required, ensuring clear API contracts.

Go linters cannot capture all style issues because human-judgment conventions like semantic line breaking, zero-value intent signaling, and named boolean extraction for complex conditions require contextual clarity decisions that automated tools are not designed to evaluate.