Why #golang devs like single-letter variable names so much? I really hate it!
@__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.