3 ms·
My main pet peeve with Golang is to use single letter or very short abbreviations when naming variables. The Golang documentation recommends what is considered
by speedgoose 3y ago
My main pet peeve with Golang is to use single letter or very short abbreviations when naming variables. The Golang documentation recommends what is considered a bad practice by most programmers communities.
- waffletower 3y agoYes, short abbreviations are brutal in long sprawling code contexts. Write in a compact, functional, and readily unit testable coding style, and those tiny variables reduce your cognitive load and bring great clarity. Use comments and/or docstrings to provide context for compact parameters and local variables once, rather than implicitly documenting with every usage.
- ctxc 3y ago>Use comments and/or docstrings to provide context for compact parameters and local variables once, rather than implicitly documenting with every usage. Context that isn't documented with every usage is context you need to remember. Trade off, but I'd much rather not have to remember multiple contexts for the same name every few hundred lines.
- classabove 3y agoAre you specifically referring to method function receiver type annotations? Those are often left shorthand but shouldn't exist out of the type definition file anyway eh?
- speedgoose 3y agoI’m referring to this guideline: > Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex. https://github.com/golang/go/wiki/CodeReviewComments#variable-names https://github.com/golang/go/wiki/CodeReviewComments#variabl...
- imtringued 3y agoOne of those is not like the other... lineCount is literally perfect meanwhile sliceIndex could be anything.
- deleted 3y ago[deleted]