Why #golang devs like single-letter variable names so much? I really hate it!

@__pity__ The official Go guidelines suggest method receivers be one or two letter names: https://go.dev/wiki/CodeReviewComments#receiver-names

Granted this doesn't extend to variables. I agree with you I prefer something more descriptive and explicit for the sake of clarity when reading code.

Go Wiki: Go Code Review Comments - The Go Programming Language

@definitepotato yes, that's a shame.

I see single-letter variables not only for method receiver, I don't know why they like it so much. A prefer self as a method receiver, btw.

@__pity__
I think short names of the variables are fine if the lifetime of these variables is short, like to be used in a loop, etc. For functiin/method signatures I like to be explicit with the names.
@definitepotato
@zylad @definitepotato i only use well-known single letter variable for loops, like i, j, or k.

@__pity__
Sometimes I also use short names (1-2 letters) if the variable is only used once or twiced. For instance if I have []byte and need to unmarshal it to get a struct, usually I would name that []byte something short because it's just intermediate state that does not affect the context. The unmarshalled data obrained from this []byte would have a proper name.
@definitepotato

Edit: s/marshal/unmarshal/

@__pity__ I'm not sure about "go devs love single-letter var names". What it's true is that Go's standard library does.
Beyond that, single-letter names are not bad per se; as always, it's a matter of context.
@chavacava I hate it. When I'm reading go code and I found a sigle-letter variable and i need to scroll/go to definition to know what that hell means t, for example.
On the other hand, llm models were trained with that ugly pattern, so they write a lot of them, even if you have rules to avoid them. It's so annoying.

@__pity__ @chavacava well, a single letter that you have tp scroll to get to the definition is bad. Really bad.

The good practice encourages to use single letter variable. But if, and ONLY if the use of the variable is on the same screen of code (so around 25-30 LOC depending on your editor).
If it's more then, then it is harmful.

@__pity__ @chavacava but a single letter var improves readability in those case better than too lengthy variable names
@dolanor @chavacava well, first, I can't believe the use single-letter variables can be called good practice, so a prefer do bad practices here and use descriptive names. Second, I don't know how it can improve readability.
@__pity__ @dolanor variable naming is an old subject thus there is a lot of serious research work on it.
Short and long names have each their cons and pros.
A nice to read code has usually a mix of short (even single-letter) and longer variable names.
@chavacava @dolanor I think is more to laziness of thinking a good name. Naming things is really hard sometimes and we are calling good practice just for that.
@chavacava @dolanor and this is counterproductive because if you see t.Send() , what's t?, so you need to scroll or go to definition.

@__pity__ @chavacava as I said earlier, needing to scroll to know the definition of a single letter variable is bad. So in that case, it is bad practice.

https://go.dev/wiki/CodeReviewComments#variable-names

https://go.dev/wiki/CodeReviewComments#receiver-names

And the longer, more explained version of it: https://google.github.io/styleguide/go/decisions#variable-names

Go Wiki: Go Code Review Comments - The Go Programming Language

@__pity__ @chavacava As a TL;DR:

1 letter variable name is OK only if:
- receiver name
- well known var names in Go context: t for testing.T, b for []byte, w io.Writer or http.ResponseWriter, r io.Reader or *http.Request, i for loop index, …
- first letter of a type if it is used in the very next lines of code. If you need to scroll, then you need to give a more explicit name, otherwise, you lose your fellow coders.

And that's about it.

```
b, _ := io.ReadAll(r.Body)
var u User
json.Unmarshal(b, &u)
posts, _ := svc.Posts.FindByAuthor(u.ID)

for _, p := range posts {
p.Author = u.Name
}
````

VS

```
responseByteSlice, _ := io.ReadAll(httpResponse.Body)
var databaseUser User
json.Unmarshal(responseByteSlice, &databaseUser)
postSlice, _ := service.PostRepository.FindPostsByAuthor(u.ID)

for _, post := range postSlice {
post.Author = databaseUser.Name
}
```

@__pity__ @chavacava of course, it's a little bit of a silly example, but I've seen people argumenting that the second version naming was better.
@dolanor @chavacava both cases are bad for me, I would use:
- response
- user
- posts
- post

@__pity__ @chavacava as long as it's not the 2nd version, I'm OK :p

For me, it's when the lines get very long without much context added to it that it's getting harder to grasp. Between 1 and 6 characters is really fine when used closed to its definition.

Also, when your function starts spanning way too many lines, you would need more descriptive names, but also, maybe the function needs to be refactored. (I'm not in the camp of functions of 20 LOC or less, though).

Again, it's more about mental load. And character load could increase mental load without giving you more knowledge of the function under analysis.

@__pity__ like the link says, https://go.dev/wiki/CodeReviewComments#receiver-names, "familiarity admits brevity". In that case I know `t` is very likely a method receiver. It need not a longer name as it is often repeated throughout the method. And provided that there is a discipline that other variable names (excluding things like i, j, k) are descriptive.
Go Wiki: Go Code Review Comments - The Go Programming Language

@gmhafiz I can't, I tried but I hate it. 😅
@gmhafiz on the other hand, when I see self in my code isn't likely a method receiver, I'm 100 % sure. 😁
@__pity__ reading other people's code sucks right 😅