Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
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).
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
- 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
- Rubocop: The Sheriff of Your Codebase