4 ms·
This is a bad take and odd place to criticize Go programmers. Go convention is often short variable names, but the only place I know where single-letter variab
by jasonshaev 7y ago
This is a bad take and odd place to criticize Go programmers.
Go convention is often short variable names, but the only place I know where single-letter variable names is encourage is for receiver methods. https://golang.org/doc/effective_go.html#methods https://golang.org/doc/effective_go.html#methods
In that case the definition of the single-letter variable is literally a line or two of code away.
- SilasX 7y agoSo is HN a good place to ask, and if so, are you able to find a perspicuous example highlighting the superior code quality?
- pbnjay 7y agoThe receiver name is likely to be used within the method, and always defined at the top of the block (and recommended to be consistent across all of the receiver's method definitions). So locality and consistency are great, improving the readability of the code. Names like "self" and "this" proscribed by other languages begin to have issues when you start dealing with nested definitions and closures. Allowing them to be explicitly named in Go avoids these ambiguities.
- SilasX 7y agoThe distinction isn't against protected words, but against more descriptive names (like "buffer" or "receiver"), and the issue is more complex functions, not one-liners. Anyway, didn't mean to put you on the spot, since you don't speak for Go programmers and weren't planning to justify the argument, I just wanted to clarify why these wouldn't satisfy the challenge.