Another rubocop/standardrb gripe:

[soulcutter@ruby.social]

Another rubocop/standardrb gripe:

Style/EmptyLiteral: Use hash literal {} instead of Hash.new

Nah, I have my own heuristics for when to use which one. If it's inside a block with braces, I assert that:

# the "approved" butthole syntax
let(:params) { {} }

looks worse than

# ain't nothing wrong with this
let(:params) { Hash.new }

#rubocop #standardrb #ruby

[soulcutter@ruby.social]

I wouldn't reject somebody else's PR that uses the butthole, but if I write Hash.new who the hell has a problem with that? Assholes, and rubocop.

[soulcutter@ruby.social]

I'm in a mood this morning.

[niclake@mastodon.social]

@soulcutter butthole syntax needs cat ears tbqh

[pointlessone@status.pointless.one]

@soulcutter OK, your mood is valid.

but also…

[gregw@mastodon.world]

@soulcutter it didn’t bother me before, but now I will never unsee this haha.

[esparta@ruby.social]

@soulcutter
re: butthole syntax
hmm OK, now I can't unsee it

{ {} }

How about use `do` blocks?

```
let(:params) do
{ }
end
```

For me it was never about performance, but making clear what's inside. I would never reject (or let rubocop) because of that.

[soulcutter@ruby.social]

@pointlessone I love this, haha. Do you think it would JIT down to the same, though?

I still prefer writing expressively, rather enforcing the best micro optimization when it’s less-readable.

[pointlessone@status.pointless.one]

@soulcutter I don’t think it would. Most JITs do not apply much optimization just translate to native code. Parser applies some optimizations when generating bytecode though. There are some specialized ops in bytecode, too.