5 ms·

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 readabl

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 11y 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 11y 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 11y 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 11y ago
  Hmm, don't think that actually happens very often, because it is so readable this way.
  - lgunsch 11y 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 11y 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 11y 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 11y ago
[deleted]
dragonwriter 11y 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 11y 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 11y 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 11y 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.

DiabloD3 11y 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 11y 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 11y 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 11y ago
Hmm, don't think that actually happens very often, because it is so readable this way.
- lgunsch 11y 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 11y 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 11y 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 11y ago

[deleted]

dragonwriter 11y 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 11y 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 11y 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 11y 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.