Use when working with Go formatting, line length, nesting, naked returns, semicolons, or core style principles. Also use when a style question isn't covered by a more specific skill, even if the user doesn't reference a specific style rule. Does not cover domain-specific patterns like error handling

Go Style Core Principles Resource Routing references/PRINCIPLES.md Read when resolving conflicts between clarity, simplicity, concision, maintainability, and consistency. references/FORMATTING.md Read when handling gofmt, line breaks, whitespace, comments, or semicolons. Style Principles (Priority Order) When writing readable Go code, apply these principles in order of importance: Priority Order 1. Clarity — Can a reader understand the code without extra context? 2. Simplicity — Is this the simplest way to accomplish the goal? 3. Concision — Does every line earn its place? 4. Maintainability — Will this be easy to modify later? 5. Consistency — Does it match surrounding code and project conventions? Formatting Run gofmt — no exceptions. There is no rigid line length limit , but Uber suggests a soft limit of 99 characters. Break by semantics, not length — refactor rather than just wrap. Reduce Nesting Handle error cases and special conditions first. Return early or continue the loop to keep the "happy path" unindented. Unnecessary Else If a variable is set in both branches of an if, use default + override pattern. Naked Returns A return statement without arguments returns the named return values. This is known as a "naked" return. Guidelines for Naked Returns OK in small functions : Naked returns are fine in functions that are just a handful of lines Be explicit in medium+ functions : Once a function grows to medium size, be explicit with return values for clarity Don't name results just for naked returns : Clarity of documentation is always more important than saving a line or two See go documentation for guidance on Named Result Parameters. Semicolons Go's lexer automatically inserts semicolons after any line whose last token is an identifier, literal, or one of: break continue fallthrough return ++ ) } . This means opening braces must be on the same line as the control structure: Idiomatic Go only has explicit semicolons in for loop clauses and to separate multiple statements on a single line. Quick Reference Principle Key Question Clarity Can a reader understand what and why? Simplicity Is this the simplest approach? Concision Is the signal to noise ratio high? Maintainability Can this be safely modified later? Consistency Does this match surrounding code? Related Skills Naming conventions : See [go naming](../go naming/SKILL.md) when applying MixedCaps, choosing identifier names, or resolving naming debates Error flow : See [go error handling](../go error handling/SKILL.md) when structuring error first guard clauses or reducing nesting via early returns Documentation : See [go documentation](../go documentation/SKILL.md) when writing doc comments, named return parameters, or package level docs Linting enforcement : See [go linting](../go linting/SKILL.md) when automating style checks with golangci lint or configuring CI Code review : See [go code review](../go code review/SKILL.md) when applying style principles during a systematic code review Logging style : See [go logging](../go logging/SKILL.md) when reviewing logging practices, choosing between log and slog, or structuring log output

go-style-core