[Ruby] My personal opinion: It’s best not to overuse the block parameter it.

April 28, 2026

In this article, Junichi Ito (https://qiita.com/jnchito/items/3fb1d28f7d75f2edc1b8) clearly articulates an idea I’ve held for quite some time. I’m sharing a translation of his work, as faithful as possible, so you can read it and share your thoughts.

Introduction: Which is the easiest to understand?

The other day, while doing a code review, I came across this code.

# コード例1

services_by_id = json['services'].index_by { it['id'] }
matched_services = project.service_ids.filter_map { services_by_id[it] } 

So, what do you think? Looking at the code above, were you able to immediately understand what it’s doing? I think the code below is much easier to understand.

# コード例2

services_by_id = json['services'].index_by { |service| service['id'] }
matched_services = project.service_ids.filter_map { |id| services_by_id[id] } 

The first line of code scould probably be abbreviated. It ‘s understandable from the context , and I think it’s still much clearer than the original code.services

# コード例3

services_by_id = json['services'].index_by { |s| s['id'] }
matched_services = project.service_ids.filter_map { |id| services_by_id[id] } 

What’s the difference between the three codes?

As some of you may have already noticed, the difference between Code Example 1 and Code Examples 2 and 3 itis whether or not they use [a specific function/method].

• Code example 1 = it Using as a block parameter
• Code examples 2 and 3 = it Not used as block parameters (explicit parameter names are given)

The only difference is this.

Shorter code isn’t always better.

Whether something is easy to understand or not is a subjective matter. Some people might think that “Code Example 1 is just as easy to understand,” while others might even prefer “Code Example 1.”

However, itI’d like you to stop and think for a moment about whether you should really use it. The reason for using “if” is…it

“ it Because it can be written more concisely.“

or

” it Because using it makes you seem more professional and cool.“

If that’s the reason, then I’d like to say, “Is that really true?”

“That” is something that needs to be understood in the same way by both the sender and the receiver.

The block parameter ittranslates to “sore” (that) in Japanese. Just like in natural language, what “sore” refers to depends on the context. In everyday conversation, if the speaker and listener both understand what “sore” is referring to, communication cannot take place.

itThe same applies to block parameters . If the person who wrote the code and the person who reads the code I tdon’t have the same understanding of “what” it is, misunderstandings can arise, and the cost of deciphering the code can increase.

If you’re unsure what “it” refers to, in everyday conversation you can simply ask, “Excuse me, what do you mean by ‘it’?” But that’s not possible with code. Communication through code is essentially one-way, from writer to reader.

it-san: “It’s me, it’s me. You know that, right?”

Whenever I itsee code that uses [this feature], I feel like the code is asking me, “It’s me, it’s me. You know who I am without me having to say it, right?” in a condescending way.

# コードを書いた人「itが何なのか、言わなくてもすぐわかるよね？」（←本当に？？）

services_by_id = json['services'].index_by { it['id'] }
matched_services = project.service_ids.filter_map { services_by_id[it] } 

In other words, it seems as though the writer’s costs (the cost of thinking up variable names and typing them) are being passed on to the reader .

In fact, when I read code like the above, in my mind,

• Um, this it…it’s processing data within a JSON file, and [‘id’] it specifies a hash, so it it’s probably a hash, but what kind of data does this hash represent…? Uh, I wonder? ? I don’t really know.
• This one it… ah, service_ids there’s one in the foreground, so maybe id?

Thus, itthere is always a cost involved in “deciphering” it (and the former is often not even deciphered).

If the writer pays a small cost, the reader will have an easier time.

If you ask me, I think, “I know the code I wrote best, so it’s cheapest to explain it myself.” In other words, itinstead of using variables, the code writer should explain “what this data contains” using the variable name.

# itを使わずに明示的なブロックパラメータでデータの中身を説明する（コードの書き手が）
services_by_id = json['services'].index_by { |service| service['id'] }
matched_services = project.service_ids.filter_map { |id| services_by_id[id] } 

While it’s true that the amount of typing and code will increase slightly, I believe that if it lowers the cost for the reader to understand the code, it’s a cost that’s well worth it.

So when should we use “it”?

However, Ruby does ithave a feature for this. As long as the feature exists, it’s up to the programmer whether to use it or not. Naturally, I, a mere engineer, itcannot tell people not to use it.

However, for the reasons mentioned above, I personally itthink it’s best not to overuse it. If I had to list some situations where it might be acceptable, I’d say it’s only really useful when you want to reduce the amount of typing in irb or the rails console, or when you’re writing a throwaway script that only you will use.

itI believe that, as a general rule, it’s best to avoid using it in code written for work purposes—that is, code that others might read or write . Of course, this is just my personal opinion.

summary

So, in this article, itI’ve expressed my personal opinion that “it’s best not to overuse block parameters.”

itIf you have a firm belief that “No, but readability doesn’t change! In fact, shorter is better!”, then I think it’s fine to continue using it as is.

However, itif you’re using it for vague reasons like “it feels more like Ruby” or “I heard that the shorter the code, the better,” itthen you should reconsider.

Even if it makes itthe code a little longer, avoiding the use of <script> will result in more readable code!