Hacker News Reader

Comment by speedgoose | Hacker News Reader

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.

View on HN

Yes, 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.

>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.

Are 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?

I’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#variabl...

One of those is not like the other...

lineCount is literally perfect meanwhile sliceIndex could be anything.

Reply on news.ycombinator.com