#standardrb — Public Fediverse posts

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

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

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

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

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

@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.

@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.

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

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

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

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

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

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

@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

@jonas I'm with you. The default #standardrb rules are so much less controversial than RuboCop's, and don't make me feel like I'm always fighting against someone else's arbitrary style choices. It's opinionated, but not about *everything*. It also doesn't go out of its way to uglify idiomatic code, which often feels like RuboCop's *raison d'être*.

Replaced our Rubocop configuration with Standard in our big Rails monolith after one too many PR with formatting discussions.

https://github.com/testdouble/standard

#RubyOnRails #Ruby #StandardRb

@postmodern it is not enabled in #standardrb

Standard just got a new superpower: Introducing the extend_config option to load RuboCop plugins and custom cops in just two lines of YAML configuration! https://link.testdouble.com/super-standard
#Ruby #StandardRB