5 ms·
It's only encouraged within certain contexts. Like it says, short lived stuff can be named "x" or "i". We already do this in almost every language. "c" for "cou
by Philip-J-Fry 6y ago
It's only encouraged within certain contexts. Like it says, short lived stuff can be named "x" or "i". We already do this in almost every language. "c" for "count" or "i" for "index" isn't specific to Go, I've seen and done that in every language I've used.
Stuff that isn't easily understood should be named appropriately but shortness is encouraged.
If you're storing an index in a global variable or a struct field then it should be called "index" not "i".
Method receivers are usually always kept short because they're pretty self explanatory and the first thing you look at in a function.
- speedgoose 6y agoi and j are very understandle. I did browse the go code randomly and for example t, s, and b are terrible variable names in my opinion in this example : https://github.com/golang/go/blob/3ce865d7a0b88714cc433454ae2370a105210c01/src/html/template/template.go#L404-L441 https://github.com/golang/go/blob/3ce865d7a0b88714cc433454ae... You can find a lot of code like this.
- yarosv 6y agoThat's easy. `b` stands for file
- earthboundkid 6y agoThat strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?
- yarosv 6y agoSure, what bothers me is how inconsistent it is. Function parameter of type Template is `t` but local variable of type Template is `tmpl`.
- earthboundkid 6y agoYes, I would have named the other one returnTmpl or something.
- speedgoose 6y agotemplate, bytes, string.
- earthboundkid 6y ago`bytes` is the name of a stdlib package. `string` is the name of a built in type. `template` is technically available, but only because it’s the name of this package, so it can’t refer to itself.
- speedgoose 6y agoTrue, but they are all available. The stdlib bytes packages is not loaded, and it's valid to use `string` as a variable name, I just tried. But even if these names were not available, I don't think using `tpl` or `t` or `b` is what should be preferred.
- drran 6y agotemplate, file, text
- earthboundkid 6y agoIs file a file object? A file path? All three are “the template”. So, they use polish-ish notation: the template as []byte, template as string, and template as *template.Template.
- drran 6y agoIn just two hours we discovered so much! Let's keep digging.
- earthboundkid 6y agoI’m not sure I follow. Is two hours a long time or a short time? I use Go a lot, so I’m used to it’s conventions. b for bytes is obvious to me because I know ReadFile returns bytes (not a file handle or a buffer), but I can see why if you lack context, it can look odd. OTOH, I don’t use Rust, so when I read snippets with 'a lifetimes, they always look “wrong” to me.
- ornornor 6y agoI never understood that. Is it really that hard to spell out full variable names? It’s so much more legible, there is autocomplete on virtually any editor (even the ones that aren’t IDEs), and you write code once but read it hundreds of times. Why even try to save 8 bytes at the expense of readability?
- kinjba11 6y agoShort variable names make code more readable in some scenarios, not less. fooBarBazThings.each(t => t.DoThing()) for (int i = 0; i < len(things); i++) { // i used here } Some local code patterns are seen so often you understand it in one go. Something like fooBarBazThings.each(fooBarBazThing => fooBarBazThing.DoThing()) for (int thingIndex = 0; thingIndex < lengthOfThings; thingIndex += 1) { // thingIndex used here } Just clutters things up.
- ornornor 6y agoI disagree. I always use descriptive variable names. I have no idea what ‘t’ is. ‘thing’ is 4 bytes more. Not the end of the world, but much more readable. Same for ‘i’ vs ‘index’.
- drran 6y agoModified obfuscator can make your code even more readable. It can simplify functions in addition to variables. Also, it improves job security, which is important in times of covid.
- twic 6y agoThis is a bit of a false dichotomy, because the names don't have to be that long. fooBarBazThings.each(thing => thing.DoThing()) It's more useful when the receiver of the method doesn't tell you as much, eg: getRecentPurchases().values().forEach(price -> priceStats.accept(price));