19 ms·

> Naming the Config parameter config is redundant. We know its a Config, it says so right there. > In this case consider conf or maybe c will do if the lifetim

• akerl_ 8y ago
  The issue w/ calling it "config" is that you end up with the confusing scenario where "config" is the object and "Config" is the type, differing only in casing.
  • pcwalton 8y ago
    Why is that confusing? Local variables are, idiomatically, never capitalized in Go, so the distinction is obvious at a glance.
    • rat9988 8y ago
      As are unexported objects.
      • ben0x539 8y ago
        Yeah, getting to idiomatically capitalize names has been pressure to move them to their own package in the past, which feels awkward.
    • akerl_ 8y ago
      Sorry. To clarify: it's not that I'm confused by the distinction between capitalized vs uncapitalized, it's that visually, "config" and "Config" look quite similar at a glance, whereas "c" and "Config" are clearly visually distinct.
  • bpicolo 8y ago
    This is a fairly go-specific issue due to its unexported vs exported convention. Many languages solve this through case conventions
• sythe2o0 8y ago
  The argument is that it is not fundamentally better to use the longer name in the given context, so why make it longer? I'd say it isn't about how long the variable takes to type either, but how long the code takes to read and parse.
• networkimprov 8y ago
  And this is worse advice: > Functions should do one thing only. ... In addition to be easier to comprehend, smaller functions are easier to test in isolation, and now you’ve isolated the orthogonal code into its own function, its name may be all the documentation required. Using single-caller functions as a substitute for comments makes the workings of a specific operation much harder to follow, as you have to jump around the source to understand its effects. A long function is easier to understand than an exploded one. Also tests should target specific operations (aka functional tests), not every single function in the program. EDIT: Every function you add becomes part of your internal API. Any API, exported or not, should comprise a cohesive collection.
  • ragona 8y ago
    > A long function is easier to understand than an exploded one. This is a pretty controversial position, and quite situational in my opinion. I absolutely agree that having to hop all over the source to understand something is frustrating, but that doesn't mean that very long functions are the right solution. Some combination of reasonably named helper methods and a function flow that makes the logic easy to parse should be the goal; either end of the spectrum is a problem.
    • networkimprov 8y ago
      I took issue with this because it's a conventional wisdom, and does a fair bit of damage. Single-caller functions attract other callers over time, gain backwards-incompatible features, and result in regressions.
      • Scramblejams 8y ago
        This is one reason I like nested functions. They’re not available to the surrounding scope so they don’t succumb to these weaknesses, while also allowing you to organize your very long function internally by task. I use ‘em in Python all the time. It’s a bummer that more languages don’t support them, though you can get there with lambdas too, sometimes at the cost of more syntax.
• tdb7893 8y ago
  I'm wrestling with this at work right now and the short names don't really bother me as they are right in that the fact that if you have the type the shorter name can make the code easier to read slightly. What annoyed me is that for those single letter names I always got collisions so my naming was inconsistent. I personally ended up doing medium length names (like conf) except for the case where there was only 1 local variable (and sometimes if there were two or three) because in that case there were no collisions and what that variable was is very very clear
• pcwalton 8y ago
  Yeah, I used to go by this advice, and I found the maintainability of my code dramatically increased when I typed out full names. I don't even use "i" for loop variables anymore. If the length is a problem, invest in an editor with autocomplete. Well-known abbreviations are fine, like "iter" and "prev", but single-letter variable names notoriously impede readability for me.
  • dilap 8y ago
    I feel like I have the opposite problem. If the name is more than a few characters long, it starts to become non-instantaneous to recognize it. Things get much easier to follow with visually-instantly-recognizable symbols. So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.
    • hackinthebochs 8y ago
      Totally agree. If you have to scroll up to be reminded what some variable means, a longer name is good. But if its usage is a few lines away from its declaration then there's no reason to add visual noise to your code.
      • shaan7 8y ago
        Its easier said than done though. We started following this few years back but then while it was "few lines away" originally, code evolved and now there are parts where its 20+ lines away. This means that short var names need to be continuously "enlarged". Well, then why not start with a "medium" name and avoid all that headache? ctx is a good enough compromise between c and context. (c can be client, config, context, certificate ... you get the point).
        • Cthulhu_ 8y ago
          Well as the article states, one-lettered variable names should only really be used in tight loops; `ctx` is a better name for e.g. a function argument.
• deleted 8y ago
  [deleted]
• ilovecaching 8y ago
  It says so in the signature, but Go code tends to have long functions, so it's kind of a fallacy to say that it's going to be easily recognizable 50 lines in because it's in the signature. Now if this were Haskell and it was a single small expression, it would be different.
• karmakaze 8y ago
  Also in this case Go makes you use types in the name since it doesn't allow function overloading.
• omeid2 8y ago
  It can be a problem with Config comes from package `config`.
• zerr 8y ago
  They don't use any IDEs or modern editors, but vim as a bare bones text entry, without syntax highlighting or word completion.
• sacado2 8y ago
  It is problematic for readability reasons as long as you are making complex expressions: configuration := NewConfiguration() configuration[word] = parameters[values[line][column]] - parameters[values[column][line]] vs conf := NewConfig() conf[w] = params[vals[i][j]] - params[vals[j][i]] It takes your brain more time to parse the first line. Now, there is an obvious limit, this is probably too much c[w] = p[v[i][j]] - p[v[j][i]] unless maybe the scope of the vars is very limited.
  • Casperin 8y ago
    The first version was too long to fit on the screen for me. Reading the second I missed the swapping of `i` and `j` -- only noticing it when I went back to the first version to figure out which parts of line I would assign to something if I were to rewrite the code.
  • dagw 8y ago
    In your example I would compromise with: conf[w] = params[vals[line][column]] - params[vals[column][line]] or even: conf[w] = params[vals[l][c]] - params[vals[c][l]] if you really want to save a couple of characters. Confusing which loop index is indexing which dimension is far too easy.