GitHub - dmmulroy/anti-slop: Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns
Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns - dmmulroy/anti-slop
Programming Guide
Summary
A practical guide to Go's naming conventions covering hard identifier rules, casing conventions (camelCase/PascalCase), acronym handling, ASCII preference, and tips for choosing descriptive names that scale with scope.
Highlights
- Hard rules: identifiers use unicode letters, digits, underscores only; no leading digits; no Go keywords
- Use camelCase for unexported and PascalCase for exported identifiers; avoid snake_case or ALLUPPERCASE
- Acronyms like API, URL, HTTP should use consistent casing (e.g., APIKey not ApiKey); write userID not userId
- Identifier length should increase with scope; exported items are capitalized; main packages mostly unexported
- Avoid non-ASCII letters, clashes with builtins or stdlib, and excessive type inclusion in names
auto-generated
Context
Audience
Go developers and programmers learning or practicing Go naming conventions and best practices
DomainGo Programming
Formatlong-form blog article
Accessfree online
Source Overview
This guide details Go's identifier rules: unicode letters, digits, underscores only; no leading digits; no keywords.
It mandates camelCase for unexported and PascalCase for exported identifiers, consistent acronym casing like userID, ASCII letters, no clashes with builtins or stdlib, and minimal type inclusion in names. Identifier length should increase with scope for descriptiveness, with exported items capitalized and main packages mostly unexported.
Topics
Related
Effective Go documentationGo style guidegofmtGo linter toolsGo builtins reference
