4 ms·
That strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?
by earthboundkid 6y ago
That 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.