Thanks for the explanation here. I didn’t know the phrase “command-query separation”. It’s also helpful to be aware that “pop” is the standard example.
In the present case, to me “getPromotedPosts” feels ambiguous between (1) “tell me which posts are promoted” and (2) “retrieve the promoted posts from somewhere”.
I might be in the minority here, but something like promotedPosts feels too much like a variable. It feels awkward to me when the name of a function isn’t a verb.
I agree about the ambiguity you point out, and for that reason I don’t feel good about the name getPromotedPosts. (Although you could establish a convention where the term “retrieve” or “fetch” is used for database access and “get” is used for situations like this.) I’m just not sure what would be better. I considered filterPromotedPosts, but that kinda sounds like it’s impure and is mutating the argument that’s passed in. Maybe filterPromotedPosts would be a good name if you’re working in a functional language though. It’s impossible to do such a mutation in a functional language, so the ambiguity goes away. I think that’s an interesting and often overlooked benefit of functional languages.
The other thing about filterPromotedPosts is that it kind of sounds like the input is promoted posts and the output is some unspecified subset of them.filterPostsForPromoted avoids that but starts to feel unwieldy to me. (But maybe I should just be more okay with unwieldy names.)
Even in an impure language I think filter sounds to me like it would return a new list rather than editing in place. That’s how the python filter function works for example, and Perl’s grep (which is basically a synonym for me), and I had to look this up but JavaScript’s filter too.
The other thing about filterPromotedPosts is that it kind of sounds like the input is promoted posts and the output is some unspecified subset of them. filterPostsForPromoted avoids that but starts to feel unwieldy to me. (But maybe I should just be more okay with unwieldy names.)
I have the exact same feelings here. It’s funny how hard this is to name! Although these issues go away if you think about the name as only one part of the boxes label, and the signature + docstring as the others. Sorta. I think it’d still be nice if the name did as much of the job as possible by itself without having to consult the signature or docstring.
Even in an impure language I think filter sounds to me like it would return a new list rather than editing in place.
In my experience the ideas of functional programming are things that a lot of people just aren’t aware of at all. I know that for me it was about seven years into my journey as a programmer before I started learning about them. Thinking about the people I have and do work with, I could very well see them using filterPromotedPosts to mutate a list of posts. So in that environment, it seems like it’d be nice to make it extra clear that “this function isn’t actually mutating anything”. (Then again, I could also see them mutating stuff in getPromotedPosts too.)
But in a different environment where the convention of “filter” being pure is strong enough, I agree with you. And I think that it’d often make sense to aspire towards this sort of environment. It’s interesting how much the right name depends on this sort of context.
Thanks for the explanation here. I didn’t know the phrase “command-query separation”. It’s also helpful to be aware that “pop” is the standard example.
I might be in the minority here, but something like
promotedPosts
feels too much like a variable. It feels awkward to me when the name of a function isn’t a verb.I agree about the ambiguity you point out, and for that reason I don’t feel good about the name
getPromotedPosts
. (Although you could establish a convention where the term “retrieve” or “fetch” is used for database access and “get” is used for situations like this.) I’m just not sure what would be better. I consideredfilterPromotedPosts
, but that kinda sounds like it’s impure and is mutating the argument that’s passed in. MaybefilterPromotedPosts
would be a good name if you’re working in a functional language though. It’s impossible to do such a mutation in a functional language, so the ambiguity goes away. I think that’s an interesting and often overlooked benefit of functional languages.The other thing about
filterPromotedPosts
is that it kind of sounds like the input is promoted posts and the output is some unspecified subset of them.filterPostsForPromoted
avoids that but starts to feel unwieldy to me. (But maybe I should just be more okay with unwieldy names.)Even in an impure language I think filter sounds to me like it would return a new list rather than editing in place. That’s how the python filter function works for example, and Perl’s grep (which is basically a synonym for me), and I had to look this up but JavaScript’s filter too.
I have the exact same feelings here. It’s funny how hard this is to name! Although these issues go away if you think about the name as only one part of the boxes label, and the signature + docstring as the others. Sorta. I think it’d still be nice if the name did as much of the job as possible by itself without having to consult the signature or docstring.
In my experience the ideas of functional programming are things that a lot of people just aren’t aware of at all. I know that for me it was about seven years into my journey as a programmer before I started learning about them. Thinking about the people I have and do work with, I could very well see them using
filterPromotedPosts
to mutate a list of posts. So in that environment, it seems like it’d be nice to make it extra clear that “this function isn’t actually mutating anything”. (Then again, I could also see them mutating stuff ingetPromotedPosts
too.)But in a different environment where the convention of “filter” being pure is strong enough, I agree with you. And I think that it’d often make sense to aspire towards this sort of environment. It’s interesting how much the right name depends on this sort of context.