Reduce object allocations by using sort_by! where it is safe

[czj]

Calling .keys() always returns a new array, so we can use sort_by!() to prevent allocating a new array.

[minad]

The lists are not long and this happens only during parser initialization. Is there a reason why you think we need this optimization? If you want to optimize, I'd prefer a more profile-driven approach instead of applying micro optimizations.

[czj]

That was simply detected and applied by static analysis.

[minad]

Okay, I am fine with such changes as long as we add the linter and/or the static analyzer to the CI pipeline. Which one did you use?

[minad]

In the other PR you proposed to add rubocop to the CI. I'd appreciate that.

[czj]

I used the configuration we use @levups in CI : it uses Rubocop with Standard Ruby rules as its base, plus uses rubocop-capybara, rubocop-minitest, rubocop-performance, rubocop-rails, rubocop-rake, rubocop-thread_safety (not all relevant for this project).

I also activated unsafe cops corrections + cops that are disabled by default (like those for performance). That should not be default but by reading warnings you can find some.

[czj]

In the other PR you proposed to add rubocop to the CI. I'd appreciate that.

We then need to agree on the code style you wish to use. Using Standard Ruby is a standard, sane, no-configuration option. Using a custom Rubocop configuration that matches the current code style is another one.

To run Rubocop / Standard on CI and comment on PRs we use Pronto via GitHub Actions.

Output looks like this :

I can apply it to this repo.

[minad]

The standard configuration is likely a good starting point for the CI. I am not sure if using pronto is a good idea in the longer run. I prefer to add "plain" rubocob to the actions file without an additional middleman.

[czj]

Pronto is a heavy dependency, but having a pull request with comments in it highlighting the issues can be a real productivity boost compared to opening the Rubocop logs in a GitHub Action.

[minad]

That's a good point. I will take a look at it.

[czj]

Great. Done in #925 and #926