Naming arguments “a” and “b” is widely considered bad practice either way, of course it’s not more informative.
Naming arguments “a” and “b” is widely considered bad practice either way, of course it’s not more informative.
As a single contributor that's trying to hack together an idea, the second option is not so bad; however, it will probably need to be changed far off in the future.
I think named block parameters are cool in the sense that they enable some expressiveness but bad in the sense that they lose some readability. I won't know how I truly feel until I have to maintain/read a large codebase where they are used.
[1,2,3].map{|n| n * 2}
to:
[1,2,3].map{it * 2}
?
It's not generalizable to multi-argument lambdas, but multi-argument lambdas are the ones that are more important to name. (e.g. with reduce, {|memo, it| memo += it})
I think as far as Ruby goes, I don't like the idea of introducing a new abstraction for something that already has a solution; however, I wouldn't villify someone for using it unless they wrote something that took a large number of arguments.
[1,2,3].map{_*2}
I think that's what Scala has. For multi-args, perhaps: [1,2,3].reduce{_1+=_2} begin anonymous function
arguments are dividend and divisor
return dividend over divisor
end
There; no cryptic one-character anything. No curly braces, no commas, no operators.