Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That strikes me as perfectly readable. t for template, b for bytes, and s for string. What else would you call them?


Sure, what bothers me is how inconsistent it is. Function parameter of type Template is `t` but local variable of type Template is `tmpl`.


Yes, I would have named the other one returnTmpl or something.


template, bytes, string.


`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.


True, 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.


template, file, text


Is 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.


In just two hours we discovered so much! Let's keep digging.


I’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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: