6 ms·

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 == {

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'}`.

squeaky-clean 10y ago
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).
- DiabloD3 10y ago
  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).
  - squeaky-clean 10y ago
    Maybe! My first real coding gig was Java, so I built up a lot of habits there. I've noticed the JetBrains IDEs do this style of naming and inference automatically. I haven't written Java in a long time, but it would make sense if that's where I picked it up. I do like the convention very much though.
- 6502nerdface 10y ago
  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.
  - mixmastamyk 10y ago
    Hmm, don't think that actually happens very often, because it is so readable this way.
    - lgunsch 10y ago
      I written python for the last 4 years, and I've never had typo problems of that nature. I find the plural form to be so idiomatic it is expected and easier to understand.
  - robmcm 10y ago
    I find this very confusing, and would much prefer to be explicit in adding the collection type. This is also useful when you have two types of collections in the same place, such as an array and dictionary.
  - squeaky-clean 10y ago
    I would normally agree, but in the case of plurals like this (at least for myself) it's instantly obviously when one is being used incorrectly. for fruit in fruit: print(fruit) My brain is screaming at me right now that the above doesn't make sense. Even with a click glance, it sticks out like a sore thumb. I'm not entirely sure why, but I'd guess it's because it mimics natural language more, so my eyes are more used to parsing that for mistakes?
- deleted 10y ago
  [deleted]
- dragonwriter 10y ago
  Even where the convention isn't to use natural language names, something like this is fairly common (e.g., in lots of fairly terse functional language the convention is to use, e.g., "xs" for a list and "x" for a member -- in some with destructuring matching on lists, the convention is "xs" for the list, "x" for the head, and "xr" for the tail (rest) of the list.)
  - RodericDay 10y ago
    this one is nice because the difference is so staggering. you just cannot mix up `x` and `xs`. `movie_collection` vs `movie_collections` is a bit trickier
- kbenson 10y ago
  Funnily enough for your example, depending on whether you are describing different types of fruit or multiples of one type of fruit, the plural of fruit may be "fruit". :) > It also goes with the "don't put the type in the name" point, which I agree with in most cases. Is that a problem in practice in Python? That's the whole reason Perl uses different sigils to denote different types of variables, which Python specifically rejected. Personally I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs). That actually does allow the same name to be used as a scalar, an array and a hash, but it's considered very bad practice. # Valid perl, but will get you nasty looks from coworkers my @fruit = qw( apple banana banana apple apple mango apple mango banana ); my %fruit; for my $fruit ( @fruit ) { $fruit{$fruit}++; # increment %fruit hash item $fruit }
  - squeaky-clean 10y ago
    > Is that a problem in practice in Python? > I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs). Not really a problem, but if you're writing more than a one-off script, such as a module you plan on sharing, it may be common that you get a mixture of concrete types coming in depending on the app and platform. I think in practice, it's actually beneficial to assume you do not know the core type of collection (if your operations will work with many/all of them). For example, a range object or generator in Python 3, but a list in Python 2. And then someone else comes along and uses your modules with sets. So with "fruits" (or something like "fruit_iter" for anyone who disagrees with plural naming), you know that you can safely iterate through it. But you may not be able to do random access, or reassignment of elements. There might be times when this matters, in which case you'd want to enforce a specific type. The only thing I do not like about this is that in Python strings are also iterables. So the difference between passing "Apple" and ["apple"] can be quite large, and yet your program will iterate through "a", "p", "p", "l", "e" with no complaints. The worst experience I've had with this was working with a web API that would return either an array of strings, or only a string if there was one result (not a 1-element array), or a dictionary of objects if there were many results. 99% percent of the time it returned the array of string, and since strings and dictionaries are iterable, it took me a while to notice the bug. I ought to learn Perl, because that's pretty cool. You're right that that example is terrible to read, haha, but I'm sure there are scenarios where it's helpful.
lmm 10y ago
That feels like an ad-hoc reinvention of half a type system. If you want to keep track of your values' types (and you should), why not use a typed language?
- RodericDay 10y ago
  the job is in Python? I like type systems when I play around with personal projects in well-typed languages
- JadeNB 10y ago
  As dragonwriter points out (https://news.ycombinator.com/item?id=11690914 https://news.ycombinator.com/item?id=11690914), Haskell best practice in naming includes things like `head (x:xs) = x`, and I think that one would not accuse this definition of involving an ad hoc reinvention of half a type system.
robmcm 10y ago
I agree, the statement, "Pluralize the variable name instead of including the name of a collection type" massively increases the chance of referring to the wrong variables based on a simple typo. Also glancing at the code you have to pay extra attention to notice a single character. In addition you have some words that don't pluralize well such as fruit or Lexus. In my opinion the more verbose and unique you can make your variable names the better, even if that means adding redundant words.

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'}`.

squeaky-clean 10y ago

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

DiabloD3 10y ago
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).
- squeaky-clean 10y ago
  Maybe! My first real coding gig was Java, so I built up a lot of habits there. I've noticed the JetBrains IDEs do this style of naming and inference automatically. I haven't written Java in a long time, but it would make sense if that's where I picked it up. I do like the convention very much though.
6502nerdface 10y ago
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.
- mixmastamyk 10y ago
  Hmm, don't think that actually happens very often, because it is so readable this way.
  - lgunsch 10y ago
    I written python for the last 4 years, and I've never had typo problems of that nature. I find the plural form to be so idiomatic it is expected and easier to understand.
- robmcm 10y ago
  I find this very confusing, and would much prefer to be explicit in adding the collection type. This is also useful when you have two types of collections in the same place, such as an array and dictionary.
- squeaky-clean 10y ago
  I would normally agree, but in the case of plurals like this (at least for myself) it's instantly obviously when one is being used incorrectly. for fruit in fruit: print(fruit) My brain is screaming at me right now that the above doesn't make sense. Even with a click glance, it sticks out like a sore thumb. I'm not entirely sure why, but I'd guess it's because it mimics natural language more, so my eyes are more used to parsing that for mistakes?
deleted 10y ago
[deleted]
dragonwriter 10y ago
Even where the convention isn't to use natural language names, something like this is fairly common (e.g., in lots of fairly terse functional language the convention is to use, e.g., "xs" for a list and "x" for a member -- in some with destructuring matching on lists, the convention is "xs" for the list, "x" for the head, and "xr" for the tail (rest) of the list.)
- RodericDay 10y ago
  this one is nice because the difference is so staggering. you just cannot mix up `x` and `xs`. `movie_collection` vs `movie_collections` is a bit trickier
kbenson 10y ago
Funnily enough for your example, depending on whether you are describing different types of fruit or multiples of one type of fruit, the plural of fruit may be "fruit". :) > It also goes with the "don't put the type in the name" point, which I agree with in most cases. Is that a problem in practice in Python? That's the whole reason Perl uses different sigils to denote different types of variables, which Python specifically rejected. Personally I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs). That actually does allow the same name to be used as a scalar, an array and a hash, but it's considered very bad practice. # Valid perl, but will get you nasty looks from coworkers my @fruit = qw( apple banana banana apple apple mango apple mango banana ); my %fruit; for my $fruit ( @fruit ) { $fruit{$fruit}++; # increment %fruit hash item $fruit }
- squeaky-clean 10y ago
  > Is that a problem in practice in Python? > I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs). Not really a problem, but if you're writing more than a one-off script, such as a module you plan on sharing, it may be common that you get a mixture of concrete types coming in depending on the app and platform. I think in practice, it's actually beneficial to assume you do not know the core type of collection (if your operations will work with many/all of them). For example, a range object or generator in Python 3, but a list in Python 2. And then someone else comes along and uses your modules with sets. So with "fruits" (or something like "fruit_iter" for anyone who disagrees with plural naming), you know that you can safely iterate through it. But you may not be able to do random access, or reassignment of elements. There might be times when this matters, in which case you'd want to enforce a specific type. The only thing I do not like about this is that in Python strings are also iterables. So the difference between passing "Apple" and ["apple"] can be quite large, and yet your program will iterate through "a", "p", "p", "l", "e" with no complaints. The worst experience I've had with this was working with a web API that would return either an array of strings, or only a string if there was one result (not a 1-element array), or a dictionary of objects if there were many results. 99% percent of the time it returned the array of string, and since strings and dictionaries are iterable, it took me a while to notice the bug. I ought to learn Perl, because that's pretty cool. You're right that that example is terrible to read, haha, but I'm sure there are scenarios where it's helpful.

lmm 10y ago

That feels like an ad-hoc reinvention of half a type system. If you want to keep track of your values' types (and you should), why not use a typed language?

RodericDay 10y ago
the job is in Python? I like type systems when I play around with personal projects in well-typed languages
JadeNB 10y ago
As dragonwriter points out (https://news.ycombinator.com/item?id=11690914 https://news.ycombinator.com/item?id=11690914), Haskell best practice in naming includes things like `head (x:xs) = x`, and I think that one would not accuse this definition of involving an ad hoc reinvention of half a type system.

robmcm 10y ago

I agree, the statement, "Pluralize the variable name instead of including the name of a collection type" massively increases the chance of referring to the wrong variables based on a simple typo. Also glancing at the code you have to pay extra attention to notice a single character. In addition you have some words that don't pluralize well such as fruit or Lexus. In my opinion the more verbose and unique you can make your variable names the better, even if that means adding redundant words.