A Guide to Naming Variables • Hacker News Board

Re: A Guide to Naming Variables

#11

Post by MrPatan » Fri, May 13, 2016, 3:07 PM UTC

andrewfromx wrote: post #3

when it's coding as fast as humanly possible, the last thing I want to do is slow down to think of good var names. I'll often just name something "foo" if I can't think of a good name and come back and rename it later. Sometimes it's a little better than foo but still not perfect but I'll leave that and move on to something else. I really don't like the idea that code must be perfect. Code is never perfect.

This is another example of how everything depends on the user. From this comment I can only assume that you code by/for yourself or with very few other people, with which you surely share a lot of time and space which makes communication in that kind of shorthand possible.

And now, I want to highlight how difficult was for me to be an understanding and constructive member of society right now, and try to explain why you may be right in some cases, instead of why you're wrong in some other possibly larger number of cases, while foaming at the mouth with an eye twitching, which is what my first internet instinct was.

Re: A Guide to Naming Variables

#12

Post by mcguire » Fri, May 13, 2016, 3:09 PM UTC

Aldo_MX wrote: post #9

bovermyer wrote: post #7

Earlier quoted context omitted.

But what happens if you die and someone else has to pick up where you left off?

someone else is going to cry because the coder is dead and the code is unreadable

Well, at least someone will be happy at the wake.

Re: A Guide to Naming Variables

#13

Post by BinaryIdiot » Fri, May 13, 2016, 3:10 PM UTC

akkartik wrote: post #8

Off-topic, but blogspot links are a constant frustration for me on the phone. It's super easy for my fingers to swipe slightly left/right when scrolling and triggering blogspot's next/previous post navigation. I can even accidentally end up slightly scrolled horizontally and have no way to see the left side again. As a result I mostly ignore blogspot links. But this seems up my alley ( http://akkartik.name/post/reada…

I hadn't realized this was a blogspot thing. I had seen this multiple times and I completely agree. Almost every single time I go to keep scrolling, somehow slightly shift my finger to the right or left and BAM I'm in another article. Very frustrating and pretty counter intuitive for how we're used to the web working.

Re: A Guide to Naming Variables

#14

Post by squeaky-clean » Fri, May 13, 2016, 3:12 PM UTC

RodericDay wrote: post #6

In dynamic languages, like Python, I think it's often good to call variables something like `fruit_list`, to quickly pick up on a bug where ie: `fruit_list == {'apple'}`.

A convention I've always done for this is to just use a plural name. There are fewer errors based on mixing up the names than you'd think, and it's very readable.

    for fruit in fruits:
      assert fruit is not 'apple'
      print(fruit)

    assert 'banana' not in fruits

etc. Especially in Python, it makes code flow very much like English.

Edit: It also goes with the "don't put the type in the name" point, which I agree with in most cases. Depending on your use case, it most likely won't matter if fruits is a list, tuple, set, generator, whatever. The plural implies an iterable interface. However, if the type does matter, I will often use it in the name (in a dynamic lang like Python).

Re: A Guide to Naming Variables

#15

Post by Aleman360 » Fri, May 13, 2016, 3:12 PM UTC

I love it when people use generic names and then add a two word comment describing what it is.

I also love it when people use primitives for time spans along with the units in the name or comment instead of TimeSpan/std::chrono.

Re: A Guide to Naming Variables

#16

Post by ebbv » Fri, May 13, 2016, 3:12 PM UTC

andrewfromx wrote: post #3

when it's coding as fast as humanly possible, the last thing I want to do is slow down to think of good var names. I'll often just name something "foo" if I can't think of a good name and come back and rename it later. Sometimes it's a little better than foo but still not perfect but I'll leave that and move on to something else. I really don't like the idea that code must be perfect. Code is never perfect.

You shouldn't be "coding as fast as humanly possible", that's how you end up with bad, brittle code full of technical debt that will be a nightmare to maintain.

Nothing's ever perfect. But code can anywhere in a spectrum from good to bad, and we should always strive to reach the good side.

Re: A Guide to Naming Variables

#17

Post by BinaryIdiot » Fri, May 13, 2016, 3:14 PM UTC

rectang wrote: post #4

Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…

I completely agree and I was a little surprised this blog post suggested that a simple 'c' was good enough. It's not good enough. While I understand the scope between two functions is different, if the variables can be unique then I say make them unique! It makes scanning, grepping, etc all so much easier.

Unless it's a very obvious index for a for loop I am against single letter variable names. Hell even if it's a for loop, if the code is so long within the loop that I have to scroll then I think the variable names need to be more obvious to keep the context with it as you scroll away from the declaration of the for loop.

Re: A Guide to Naming Variables

#18

Post by DiabloD3 » Fri, May 13, 2016, 3:16 PM UTC

squeaky-clean wrote: post #14

RodericDay wrote: post #6

In dynamic languages, like Python, I think it's often good to call variables something like `fruit_list`, to quickly pick up on a bug where ie: `fruit_list == {'apple'}`.

A convention I've always done for this is to just use a plural name. There are fewer errors based on mixing up the names than you'd think, and it's very readable. for fruit in fruits: assert fruit is not 'apple' print(fruit) assert 'banana' not in fruits etc. Especially in Python, it makes code flow very much like English. Edit: It also goes with the "don't put the type in the name" point, which I agree with in most…

That has always been a Java thing to me. I see it a lot in Sunacle, Apache, and Google originated code (which, for some reason, all three have their own different culture on how to write Java, but it's kind of subtle).

Re: A Guide to Naming Variables

#19

Post by 6502nerdface » Fri, May 13, 2016, 3:17 PM UTC

squeaky-clean wrote: post #14

RodericDay wrote: post #6

In dynamic languages, like Python, I think it's often good to call variables something like `fruit_list`, to quickly pick up on a bug where ie: `fruit_list == {'apple'}`.

A convention I've always done for this is to just use a plural name. There are fewer errors based on mixing up the names than you'd think, and it's very readable. for fruit in fruits: assert fruit is not 'apple' print(fruit) assert 'banana' not in fruits etc. Especially in Python, it makes code flow very much like English. Edit: It also goes with the "don't put the type in the name" point, which I agree with in most…

I've always considered it a dangerous idiom in dynamic typed languages like Python to create identifiers that differ from each other by only a single character (fruit/fruits), point to completely different objects, and are used in close proximity to each other. It's just asking for a hard-to-detect typo that will blow up at runtime.

Re: A Guide to Naming Variables

#20

Post by bryanlarsen » Fri, May 13, 2016, 3:17 PM UTC

ebbv wrote: post #16

andrewfromx wrote: post #3

when it's coding as fast as humanly possible, the last thing I want to do is slow down to think of good var names. I'll often just name something "foo" if I can't think of a good name and come back and rename it later. Sometimes it's a little better than foo but still not perfect but I'll leave that and move on to something else. I really don't like the idea that code must be perfect. Code is never perfect.

You shouldn't be "coding as fast as humanly possible", that's how you end up with bad, brittle code full of technical debt that will be a nightmare to maintain. Nothing's ever perfect. But code can anywhere in a spectrum from good to bad, and we should always strive to reach the good side.

Exactly. Good variable names are one of the best "bang for your buck" optimizations available. There might be other things you can do to make your code better, but few so easy and impactful.