Hacker News Reader

Comment by Philip-J-Fry | Hacker News Reader

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.

View on HN

i 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/3ce865d7a0b88714cc433454ae...

You can find a lot of code like this.

That's easy. `b` stands for file

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

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.

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.

I 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?

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

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

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

This 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));

Reply on news.ycombinator.com