{"dataset":{"id":"00000000-0000-0000-0000-000000000014","slug":"go-best-practices","name":"Go best practices","description":"Source-linked guidance on Go fundamentals from go.dev: error handling, gofmt formatting, goroutines and channels, naming conventions, and module dependency management. Scoped to Go; not a general programming corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Managing module dependencies","sourceUrl":"https://go.dev/doc/modules/managing-dependencies","text":"When Go code uses external packages, those packages are distributed as modules and become dependencies, and Go provides dependency management tools that help keep applications secure while incorporating them. Dependency changes are made with Go commands, which edit the go.mod file so its contents stay valid; go help command-name, as in go help mod tidy, gives command-line reference. The typical workflow is to locate useful packages on pkg.go.dev, import them, enable dependency tracking by putting the code in its own module with go mod init — whose argument is the module path, ideally the repository location of the source — and then upgrade or downgrade dependency versions over time. Publishing is decentralized: developers make modules available from their own repositories with version numbers, and a version numbering convention conveys stability and backward compatibility guarantees. Making an editor or IDE aware of Go modules eases the work. Scope: Go. Reviewed October 4, 2026.","id":"go-best-practices:Managing module dependencies","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Naming conventions","sourceUrl":"https://go.dev/doc/effective_go#names","text":"Names in Go have semantic effect: visibility of a name outside a package is determined by whether its first character is upper case. Package names become accessors for the package's contents, so they should be short, concise, and evocative — by convention lower case, single-word names with no underscores or mixedCaps. A package name need not be unique across all source code, and it is conventionally the base name of its source directory: the package in src/encoding/base64 is imported as \"encoding/base64\" but named base64. Exported names avoid repetition because importers always address them with the package name, so bufio has Reader, not BufReader, and ring's constructor is just New, seen as ring.New. Long names do not automatically improve readability; a helpful doc comment is often more valuable. Multiword names use MixedCaps or mixedCaps rather than underscores. Scope: Go. Reviewed October 4, 2026.","id":"go-best-practices:Naming conventions","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Concurrency with goroutines and channels","sourceUrl":"https://go.dev/doc/effective_go#concurrency","text":"Go encourages passing shared values around on channels rather than actively sharing memory between separate threads of execution, so only one goroutine has access to a value at any given time and data races cannot occur by design — captured in the slogan \"Do not communicate by sharing memory; instead, share memory by communicating.\" Mutexes remain suitable for cases like reference counts. Goroutines are lightweight functions executing concurrently in the same address space; their stacks start small and grow via heap allocation, and they are multiplexed onto multiple OS threads so others keep running if one blocks on I/O. Prefixing a call with the go keyword runs it in a new goroutine, which exits silently when the call completes, and function literals act as closures that keep referenced variables alive. Go's approach originates in Hoare's CSP and can be seen as a type-safe generalization of Unix pipes. Scope: Go. Reviewed October 4, 2026.","id":"go-best-practices:Concurrency with goroutines and channels","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Formatting with gofmt","sourceUrl":"https://go.dev/doc/effective_go#formatting","text":"Go delegates formatting to the machine to minimize contention and preserve developer time. The gofmt program enforces a standard style of indentation and vertical alignment, handling comments and structure field alignment automatically; go fmt is the same tool operating at the package level. If gofmt's output seems incorrect, rearrange the program or file a bug about gofmt rather than working around the tool. Indentation relies on tabs, which gofmt emits by default, with spaces used only if necessary. Go imposes no line length limit; long lines may be wrapped and indented with an additional tab. Control structures like if, for, and switch require no parentheses, and the operator precedence hierarchy is shorter and clearer than in C or Java. All Go code in the standard packages has been formatted with gofmt, ensuring consistency across the ecosystem. Scope: Go. Reviewed October 4, 2026.","id":"go-best-practices:Formatting with gofmt","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Error handling with the error interface","sourceUrl":"https://go.dev/doc/effective_go#errors","text":"Go's multivalue return simplifies returning detailed error descriptions alongside normal values, a practice considered good style. Errors conventionally implement the built-in error interface, defined by an Error() string method. Library writers may implement richer models, such as os.PathError, which records the operation, file path, and underlying system error. Its Error method generates informative strings like \"open /etc/passwx: no such file or directory\", including context useful even when printed far from the call site. Error strings should ideally identify their origin via prefixes naming the operation or package, as seen in \"image: unknown format\". Callers requiring precise details can use type switches or assertions to inspect specific errors. For instance, one might check if an error is a *os.PathError and examine its internal Err field to handle recoverable failures, such as running out of disk space, by taking corrective action like deleting temporary files. Scope: Go. Reviewed October 4, 2026.","id":"go-best-practices:Error handling with the error interface","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}