3 ms·
On the other hand, sometimes it’s better to avoid naming functions, especially if they’re small and only used once. For instance, if I’m doing something like ‘m
by bradrn 4y ago
On the other hand, sometimes it’s better to avoid naming functions, especially if they’re small and only used once. For instance, if I’m doing something like ‘map (\(x,y) -> (x,y+1))’ to increment the second element of each item in a list (using Haskell syntax), naming the anonymous function won’t necessarily make anything clearer. Or consider this example from my own code:
zipWith (\i m -> fmap (i,) m) [0..]
Sure, I could rewrite it as ‘zipWith prependToEachElement [0..]’, but if you know Haskell that’s not all that much shorter or clearer, especially for a function which might only be used once in the whole program.
- skybrian 4y agoThis assumes you're writing generic, mathematical code. Maybe that's common in Haskell, and I agree that there often aren't helpful names in that situation. But usually, if you're working with a list, it's a list of something specific, and the names should reflect that. If we're doing graphics and those (x,y) points are interpreted as points on a graph, then it's really: moveUpOne = (x,y) => (x,y + 1) map(moveUpOne, points) Or maybe it's moveDownOne? Depends on your coordinate system. Similarly, you're probably prepending to a list for some application-specific reason. The code should use application-specific jargon.
- antonvs 4y agoIn Haskell you can implement moveUpOne as: moveUpOne = fmap (+1) ...which uses a map over a functor, in this case a tuple. But once you're familiar with functors, there's not that much benefit in naming something like that, much as you wouldn't typically define `add1 = (+1)`.
- skybrian 4y agoThat's significantly less readable since you can't see that you're working with ordered pairs that have x and y coordinates. Don't hide the data structure.