5 ms·

Interestingly Golang encourages one letter variable names and it's not sarcasm this time : https://github.com/golang/go/wiki/CodeReviewComments#variable-names h

• 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 ago
    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/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 ago
      That's easy. `b` stands for file
    • 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 ago
        Sure, 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 ago
          Yes, I would have named the other one returnTmpl or something.
      • speedgoose 6y ago
        template, 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 ago
            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.
      • drran 6y ago
        template, file, text
        • earthboundkid 6y ago
          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.
  • ornornor 6y ago
    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?
    • kinjba11 6y ago
      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.
      • ornornor 6y ago
        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’.
      • drran 6y ago
        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.
      • twic 6y ago
        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));
• vsareto 6y ago
  I kind of agree with their reasoning, the exception being when you can have a lot of complicated looping/control flow breaks or transient variables close to their usage. Seeing 'array[i][j][k]' is never fun.