It's a good idea to write _what_ something does, especially when the algorithm seems very "generic".
I'll a thousand times rather have
// Create users from id's
userList = theblackmagiconeliner;
Than a 20 line version of it where I'm left having to read through it to determine "oh, it made users from a list of id's" or even just.. having to read through it to find out if there's other stuff plugged in because "it could go there" or even just finding where it ends and actual work starts.
userList = userListFromUserIdList(userIds);
is also perfectly acceptable, but if it's only used once in that file, I'd prefer the blackmagiconeliner..
If it's only used once in the project, I'd also prefer that to having another file just for that function. Just do the work and get on with it.
Put the 20 line version in a properly named function, even if it's only used once. There are two reasons for this:
1. You're probably doing something else where you don't want to stop and decipher a magic one-liner. That comment is a great name for that function.
2. Now that you have a function, write a test. Now that you have a test, your coworkers won't be tempted to tuck extra stuff in that function, because everyone hates editing tests.
Exactly because now.. what used to be a menial computation required to get from A to B, has become a Thing, its existence has been justified not just by the declaration of a named function, but it has been blessed by the allocation of holy inodes and filesystem entries and versioning control entries, and oh god no, now it's been promoted to "actually important piece of infrastructure" by the greasy hand of a unit test. It has become a goal in and of itself.. What used to be a worthless piece of "I have Id's I need user objects"-getting-it-to-work has ascended and become immortal. Hours of work will now replace minutes, it adds drag to the entire system, not just in code size and bulk, but in developer mindshare, it exists and must therefore be considered and payed some amount of respect.
It is painless to delete a single line of "doing stuff" when refactoring something..
But alas, in the end, the function call is deleted, but it lives on, either unreferenced or shows its ugly face in other parts of the code, now mutilated and mutated to support "that thing that sounds like what it did but not quite"..
No, flamethrowers alight! Kill it with fire! Let it never be born.
And I'm actually very much in favor of DRY. But that mainly is about repetition, not about spawning as much "structure for the sake of structure" as possible.
That single line of magic is still a Thing, just a thing without a name or any way to check that you didn't make a mistake in writing it.
If this magic single line is a map over a list, that's fine - but I've seen some deeply unholy one-liners. Like, 600 characters for no reason. Don't do that!
I'll a thousand times rather have
// Create users from id's
userList = theblackmagiconeliner;
Than a 20 line version of it where I'm left having to read through it to determine "oh, it made users from a list of id's" or even just.. having to read through it to find out if there's other stuff plugged in because "it could go there" or even just finding where it ends and actual work starts.
userList = userListFromUserIdList(userIds);
is also perfectly acceptable, but if it's only used once in that file, I'd prefer the blackmagiconeliner.. If it's only used once in the project, I'd also prefer that to having another file just for that function. Just do the work and get on with it.