Hacker News Reader

Comment by pawelduda | Hacker News Reader

Yeah I tried it a few times and there was usually pushback during code review. I agree though, saving a few characters is not worth the readability you lose vs even something like `users.map { |u| (...) }`

View on HN

Aesthetically, yes, I agree (subjectively) that "_1" is uglier than "|u|".

However, saying that the latter is "more readable" lacks foundation imo... both are conventions, both are simple to understand, and you can adapt to either quickly. I'd argue this is a case of "familiarity"/"readability" confusion.

A more practical argument is that "|u|" is more widely known by inexperienced ruby devs, and hence has an advantage on larger teams, especially those with turnover. With that said, I agree with author's position.

In practice, you wouldn't use |u| either. You'd use |user|. I would only allow single character variables if they are scoped entirely within one line of code. But even then, best practice is to use good variable names, so I'd still prefer `users.map{ |user| do_something(user) }` or whatever. I use the to_proc pattern for existing methods on the object like `users.map(&:email)`.

The only case where I've used a shorthand pattern like _1 is with regex matching where the matched groups are not named, so $1, $2, $3 refer to the first, second, third matched groups, etc. Having worked a lot with csvs (mentioned in an example), referencing the header (or creating one) has always been really valuable, using numbers is asking for trouble when the spec inevitably changes or when a dev wants to know if a script will work with some new file.

Imo using "good variable names" in cases where that variable is effectively functioning as nothing more than a syntactically necessary placeholder for a point-free phrase is a clear (if well-intentioned) mistake. It makes the code noisy and verbose for no benefit.

To take the exact example you gave, `users.map{ |u| do_something(u) }` is unambiguously better than `users.map{ |user| do_something(user) }`.

What we really want is `users.map{ do_something }`. It is only happenstance that ruby allows this form for methods only via `users.map(&:some_method)`, and we are stuck with forced variable names when calling other functions. Still, we can reduce the boilerplate as much as possible, and this is the basic argument of the article.

Also fine: `users.map{ |x| do_something(x) }` (the "x" as a conventional placeholder for the meaningless but syntactically necessary placeholder) and `users.map{ do_something(_1) }` (the _1 accomplishing the same thing). In either case, the "meaningful variable" is already there in the name "users" -- repeating it is mere stutter and detracts from, rather than enhancing, clarity.

The exception (as you noted) would be a longer multiline block where repeating `user` can aid short term memory, especially if the block contains other local variables.

> It is only happenstance that ruby allows this form for methods only via `users.map(&:some_method)`, and we are stuck with forced variable names when calling other functions.

Not sure what you are trying to say here, because there are so much odd about this that it is hard to penetrate.

First, & works on proc-able objects (those that are Procs or can be converted to them via #to_proc), not "methods", and what you show it being used with is a symbol, not a method. Symbol#to_proc on a symbol s produces a proc that is functionally something like:

  ->(*args, **kwargs) { args[0].send(s, args[1..-1, **kwargs] }

While that's complicated, the upshot is that it creates a proc that calls the method whose name is the symbol & was applied to on its first argument, passing its remaining arguments as the arguments to the method.

> What we really want is `users.map{ do_something }`.

But if you want to pass a method on self, the only thing in Ruby that you can call like do_something(x), to map, you can do that without an expllcit block already, by using the Object#method method, which returns a Proc that is equivalent to calling the method:

  users.map &method(:do_something)

And if you want to call a Proc object in a local variable called do_something to map (the closest thing to a "non-method function" that exists in Ruby), you can do that without an explicit block, even more concisely, because you don't have to convert it to a Proc first:

  users.map &do_something

Sigh. Yes, I am aware of the technicalities you describe. I thought my point was clear without my needing to be pedantically accurate.

In many languages (even in JS!) you can just map a function point-free, rather than having to introduce a variable just because syntax demands it, or worry about which syntax to use depending on if the "function" you're calling is a method on the object being mapped or something else. It's all noise.

> you can do that without an expllcit block already, by using the Object#method method, which returns a Proc that is equivalent to calling the method:

> users.map &method(:do_something)

Again, I am aware, and the ugliness of that solution proves the point I was trying to make -- it is even worse than the block syntax with a variable.

> In many languages (even in JS!) you can just map a function point-free,

Yes, in many languages, "functions" are a thing that exists. In Ruby, there is no such thing as a function. The concept does not exist.

Which is why it is bizarre to talk about what you can and can't do with "functions" in Ruby, and to call kinds of different not-function things (including symbols, of all things) "functions" in that discussion. Its just applying language that makes no sense.

>using "good variable names" in cases where that variable is effectively functioning as nothing more than a syntactically necessary placeholder for a point-free phrase is a clear (if well-intentioned) mistake.

If variable names are well picked they provide guiding context hints that ease understanding. If you have only a terse pack of symbols, deciphering the code will be longer because you have to go trough more contextualization to understand where the code take place and what it actually operates over for which purpose.

I find this too cluttered: `billing_subscriptions.each { |billing_subscription| billing_subscription.status = ACTIVE }`

This reminds me a lot of using(&:blabla). I'd prefer it: `billing_subscriptions.each { |bs| bs.status = ACTIVE}`

But don't mind me I'm just bikeshedding

We outlawed it immediately via Rubocop but I use it all the time in IRB.

We also don't allow single letter variable names. I'm an old school rubyist and find this to be an annoying constraint that can't be auto-corrected so it adds a little friction to writing code but arguing for more terse code is always a losing proposition so I just deal with it.

Yes, in repl it's convenient. I don't mind single letter block var names if the block spans one line :)

`ii` it is then

sigh, I once encountered a PFY junior who named all variables some variation on `nx`, so `n1`, `n2`, `n99` because they 'were all just numbers'.

Using `i`, `j`, and `k` as index variables is not bad practice.

Well, my attempt at a humorous aside didn't land.

To be strictly serious we are talking about block parameters in ruby which contain the values yielded to it which, in an enumeration, is likely to be a value object from a collection and only occasionally an index (where you've explicitly chained `#with_index` for e.g.). If you are nesting deep enough in ruby to call for `k` then, yes, it would be bad practice.

I would quit if I had to write multi-character index variables.

_1 takes two characters per use, single-character explicitly named variables take one character per use plus 3 per variable (4 for the first), counting spaces, so you save two characters (three for the first) if the variable is used once, minus one per additional use of a variable.

With only one variable, and sometimes with very simple expressions with more than one, you probably get a readability benefit by avoiding stuttering:

  { _1 + _2 }

reads a little better than:

  { |x, y| x + y }

But with any even slightly complex expression in the block, that goes from a benefit to a cost.

Reply on news.ycombinator.com