-
1) Auto-correcting a whole (large) codebase at once with tons of offenses and dozens of active branches should be used with caution. Merge conflicts, blame pollution (ok, can be solved with .git-blame-ignore-revs, though can hardly remember any project using it). Though, the most important argument is that auto-correct can introduce bugs. Unfortunately, even safe autocorrect can be unsafe. Recently, I broke one popular project (with a decent, but not 99.999% test coverage) with a single "safe" auto-correction commit 🙂 (This issue).
-
Judoscale
Save 47% on cloud hosting with autoscaling that just works. Judoscale integrates with Rails, Sidekiq, Solid Queue, and more to make autoscaling easy and reliable. Save big, and say goodbye to request timeouts and backed-up job queues.
-
2) Inline comments add a lot of noise. Encouraging developers to fix style issues? Or encouraging them to spend time on irrelevant fixes while working on features? The TODO approach should be considered as a prevention measure. The primary goal is to write new code in style. Unfortunately, if there are many large classes/files, TODO config can silent new offenses. To overcome this, we can use alternative tools, like rubocop-gradual.
Related posts
-
Utilities for refactoring and upgrading Ruby code based on ASTs
-
Mastering Linters : A Code Quality Assurance Comprehensive Guide using Ruby on Rails
-
code review / feedback for improvement
-
I live and work in the US where protests against police brutality have been ongoing for days, and coming to work this week the word "cop" has an uncomfortable feeling about it.
-
Ruby 2.7.8 Released