4 ms·

Naming stuff is not trivial and not a bikeshedding.

bigpeet 7y ago
There should be naming guidelines just like how a team should have style guidelines. The discussions should happen when creating (or updating) these guidelines. Then these guidelines should be followed, no need for long discussions during code reviews. Variable name does not follow guidelines => Mark it as an issue, defer to the guidelines move on.
- raverbashing 7y ago
  Some people will just find it as an excuse to go all over it the naming issue. Worse than the "80 columns is the limit" people, because after all 80 columns is 80 columns. But there's no "ideal name" for some people.
- closeparen 7y ago
  No. The purpose of a name is to convey meaning to the reader. There is exactly one valid complaint about a name: “I’ve read this carefully and I still don’t know what it means.” A standards-compliant name that interferes with understanding is not okay. A name everyone gets, which happens to not follow a rule in some rulebook, is probably fine.
raverbashing 7y ago
No, sorry. Wasting too much time is BS. Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus. Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line. More important than picking the perfect name: - Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life through the code path. If bolt is not a great name you can change later. - Being easy to remember and type. There's no point with TurningWheelThatGoesSqueak and having a TurningWheelThatGoesSquak and a TurningWheelThatGoesSquewk this will only make the developers go crazy. Simplify. And yes bikeshedding is bad. I just find it too ironic that parent's username reminds me of the place that took bikeshedding to the extremes.
- alanfranz 7y ago
  What is a good name? Sometimes the failure at finding a good name (and taking 30 minutes to name your variable) means your abstraction is not good and/or your variable encloses multiple concepts. Of course, a short-spanned internal-only variable used just once or twice doesn't deserve a 30-minutes debate; OTOH a public variable which could be externally exposed by a class could require a bit of thinking.
  - diggan 7y ago
    Elements of Clojure is an excellent book that goes through what a good name is and what it should represent. Don't be put off by the "Clojure" in the title, the book is really not about Clojure but about programming, using Clojure for its samples. You can read a sample chapter online, which is the chapter about naming. Highly recommended! https://leanpub.com/elementsofclojure/read_sample https://leanpub.com/elementsofclojure/read_sample
- onion2k 7y ago
  You're naming a variable, not the title of your Magnum Opus. You're naming a variable, and that name is probably the most important documentation about that specific point in the code. A lot of the time a useful name will be quite obvious, so you should use one. If you see code that has variable names like a, i, myVar, value, etc then it's usually a sign the developer didn't think very hard about the code that they were writing. Using a name that gives some context to the data the variable should hold is massively useful to the next developer to work on the code (which is usually you, so you'll be thankful you did).
  - raverbashing 7y ago
    'a' and 'i' are perfect for indexes or range traversals. Yes, myVar is bad. You can always read the context and see 'for value in list_of_values' or understand what's it that you're working with right now. Yes, be more explicit on the tricky parts, but sometimes i = i+1 is just fine.
    - 7y ago
commandlinefan 7y ago
There are two difficult problems in software engineering: cache invalidation, naming things, and off-by-one errors.
- abiogenesis 7y ago
  I can vouch for problems #0 and #1 but I've never experienced #2.

There should be naming guidelines just like how a team should have style guidelines. The discussions should happen when creating (or updating) these guidelines. Then these guidelines should be followed, no need for long discussions during code reviews. Variable name does not follow guidelines => Mark it as an issue, defer to the guidelines move on.

raverbashing 7y ago
Some people will just find it as an excuse to go all over it the naming issue. Worse than the "80 columns is the limit" people, because after all 80 columns is 80 columns. But there's no "ideal name" for some people.
closeparen 7y ago
No. The purpose of a name is to convey meaning to the reader. There is exactly one valid complaint about a name: “I’ve read this carefully and I still don’t know what it means.” A standards-compliant name that interferes with understanding is not okay. A name everyone gets, which happens to not follow a rule in some rulebook, is probably fine.

raverbashing 7y ago

No, sorry. Wasting too much time is BS. Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus. Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line. More important than picking the perfect name: - Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life through the code path. If bolt is not a great name you can change later. - Being easy to remember and type. There's no point with TurningWheelThatGoesSqueak and having a TurningWheelThatGoesSquak and a TurningWheelThatGoesSquewk this will only make the developers go crazy. Simplify. And yes bikeshedding is bad. I just find it too ironic that parent's username reminds me of the place that took bikeshedding to the extremes.

alanfranz 7y ago
What is a good name? Sometimes the failure at finding a good name (and taking 30 minutes to name your variable) means your abstraction is not good and/or your variable encloses multiple concepts. Of course, a short-spanned internal-only variable used just once or twice doesn't deserve a 30-minutes debate; OTOH a public variable which could be externally exposed by a class could require a bit of thinking.
- diggan 7y ago
  Elements of Clojure is an excellent book that goes through what a good name is and what it should represent. Don't be put off by the "Clojure" in the title, the book is really not about Clojure but about programming, using Clojure for its samples. You can read a sample chapter online, which is the chapter about naming. Highly recommended! https://leanpub.com/elementsofclojure/read_sample https://leanpub.com/elementsofclojure/read_sample
onion2k 7y ago
You're naming a variable, not the title of your Magnum Opus. You're naming a variable, and that name is probably the most important documentation about that specific point in the code. A lot of the time a useful name will be quite obvious, so you should use one. If you see code that has variable names like a, i, myVar, value, etc then it's usually a sign the developer didn't think very hard about the code that they were writing. Using a name that gives some context to the data the variable should hold is massively useful to the next developer to work on the code (which is usually you, so you'll be thankful you did).
- raverbashing 7y ago
  'a' and 'i' are perfect for indexes or range traversals. Yes, myVar is bad. You can always read the context and see 'for value in list_of_values' or understand what's it that you're working with right now. Yes, be more explicit on the tricky parts, but sometimes i = i+1 is just fine.
  - 7y ago

commandlinefan 7y ago

There are two difficult problems in software engineering: cache invalidation, naming things, and off-by-one errors.

abiogenesis 7y ago
I can vouch for problems #0 and #1 but I've never experienced #2.