Trying to grease the skids on two #standardrb rule changes:

* https://github.com/standardrb/standard/pull/706
* https://github.com/standardrb/standard/pull/707

I also tried making my own StandardRb plugin too apply these rules, but was thwarted by the sly plugin implementation

https://github.com/standardrb/standard?tab=readme-ov-file#extending-standard
> While neither can change the rules configured out-of-the-box by Standard, they can define, require, and configure additional RuboCop rules.

I get why that is, but dang it means that I don't get my own standards

#ruby

Allow adjacent oneline method definitions by soulcutter · Pull Request #706 · standardrb/standard

The purpose of oneline methods is a terser format for simple methods, similar to defining variables. This rule change allows oneline methods to be grouped more-closely together, just as you might g...

GitHub

@alexanderadam @cam No, but I know lots of teams where EVERYONE basically runs `rubocop --regenerate-todo` before every commit because they don't have the time, interest, or agreement to prevent untuned #RuboCop from uglifying or distorting code. #Standardrb, and to a lesser extent https://github.com/rails/rubocop-rails-omakase, have many fewer argument-inducing rules so people actually *use* the linters & style guides rather than just ignoring them.

IMHO the default RuboCop rules ruin good #RubyLang code. YMMV.

GitHub - rails/rubocop-rails-omakase: Omakase Ruby styling for Rails

Omakase Ruby styling for Rails. Contribute to rails/rubocop-rails-omakase development by creating an account on GitHub.

GitHub
@mike_k Defaulting to double-quotes is one of the things I love about #standardrb. Actually, the RuboCop Rails Omakase gem is pretty good, too. The only rule in there I hate is the default of enforcing spaces inside square brackets. You can tune that, but then it wants to change a bunch of Rails config files and such, too. Oh, and complaining about trailing commas in Hash and Array literals. Either way, better than the dozens of violations standard #RuboCop emits out of the box!

I'm a fan of the #standardrb gem, but so far the https://github.com/rails/rubocop-rails-omakase gem that's the new default for Rails 7.2.0.beta2 isn't too bad. Many of the tuned defaults work well out of the box. The only rule I vehemently disagree with in my testing so far is adding spaces inside Array and Hash literals.

This can be modified, of course. My point is that the defaults are pretty sane compared to the usual out of the box experience with untuned #RuboCop.

GitHub - rails/rubocop-rails-omakase: Omakase Ruby styling for Rails

Omakase Ruby styling for Rails. Contribute to rails/rubocop-rails-omakase development by creating an account on GitHub.

GitHub

Been using LazyVim as a base for my neovim config this week, and it’s pretty great. If nothing else it’s a good complete example of a full IDE-quality config. Got it working with standardrb’s LSP-mode for Ruby linting suggestions + format on save. 👌

https://www.lazyvim.org/

https://github.com/standardrb/standard?tab=readme-ov-file#language-server-protocol-support

#NeoVim #Vim #Ruby #RubyOnRails #StandardRB

🚀 Getting Started | LazyVim

LazyVim is a Neovim setup powered by 💤 lazy.nvim

Just ran across this gem from @palkan at @evilmartians. I detest #frozenstring literals, think default #RuboCop is on crack, and am unconvinced that String reuse is always better than being GC-able.

#Standardrb is less painful than RuboCop's defaults. Now add #Freezolite to solve problems around frozen strings in a sane, tunable, and project-wide way rather than at the file or interpreter level. It allows for inclusions & exclusions, making it fit more use cases IMHO.

https://github.com/ruby-next/freezolite

GitHub - ruby-next/freezolite: Automatically add frozen_string_literals to selected files at compile time

Automatically add frozen_string_literals to selected files at compile time - GitHub - ruby-next/freezolite: Automatically add frozen_string_literals to selected files at compile time

GitHub
@ingemar @evilmartians They make some really cool stuff. I wish more people knew about the things they build like #standardrb and #RubyNext, which is an amazing piece of #metaprogramming for creating forward compatibility even when running legacy #RubyLang versions. Glad to know I'm not the only fan!
@todd_a_jacobs 💯 We had to ditch Rubocop because it became unmanageable and left the code in a worse state than before. Now we're using #StandardRB. We're happy, and the code is beautiful.
@evilmartians

@here_for_code @evilmartians I like #standardrb because it uses #RuboCop but only implements basic and non-controversial rules that help with linting.

I occasionally use #RubyMine for the (putatively) automated refactorings and to play around with #AI integrations, but I'm a #CLI guy and don't find IDE's very intuitive. I use heavily customized #vim, #ack or #thesilversearcher, and #ctags for day to day stuff. It just seems faster to me, but that could just be muscle memory and habit. 😄

#RubyOnRails has always been opinionated, and I am too. The #RuboCop defaults are always more trouble than they're worth; I use #standardrb from @evilmartians instead for most projects. However, I'll give this new opt-out "feature" the benefit of the doubt for now if the rules are actually well-tuned.

https://twitter.com/dhh/status/1740754874474868959

DHH (@dhh) on X

Rails 8 will ship with a default Rubocop linter for the first time. The styles will come from this omakase menu. Substitutions will be easily achieved (and even encouraged). Find the Ruby flavor that tickles your fancy! https://t.co/4UW0Eberpl

X (formerly Twitter)