We use rubocop heavily at GitLab. I'm generally happy with it, and we have a largely sane set of linters. I think when your codebase gets to a certain size and you have a lot of engineers working on it, having some sane defaults is very beneficial and helps standardise the codebase a bit.
Where I think rubocop really shines is in picking up _problem_ code, like potential bugs, performance issues, or errors, in advance. We also use it heavily when deprecating older modules/classes, like replacing JSON calls with our own wrapper.
It does, however, sometimes suggest something totally bonkers: https://gitlab.com/gitlab-org/gitlab/-/issues/271570, but it's fairly trivial to skip it. After all, humans should be allowed to say that the linter is wrong and either ignore it or suggest an improvement, and that's a process issue rather than a rubocop issue :)
Not everyone is going to agree with every cop you enable, but the goal is standardisation rather than appeasing everybody. If something is particularly contentious then I would suggest removing/disabling that cop.
Every few years at GitLab we do seem to get a singlequotes vs doublequotes cop argument crop up, which is why we (thankfully) still don't have any requirement around those. Team doublequotes represent!
Edit: Oh and unrelated to the content of the article, but I really like the design and colour palette of the blog.
Where I think rubocop really shines is in picking up _problem_ code, like potential bugs, performance issues, or errors, in advance. We also use it heavily when deprecating older modules/classes, like replacing JSON calls with our own wrapper.
It does, however, sometimes suggest something totally bonkers: https://gitlab.com/gitlab-org/gitlab/-/issues/271570, but it's fairly trivial to skip it. After all, humans should be allowed to say that the linter is wrong and either ignore it or suggest an improvement, and that's a process issue rather than a rubocop issue :)
Not everyone is going to agree with every cop you enable, but the goal is standardisation rather than appeasing everybody. If something is particularly contentious then I would suggest removing/disabling that cop.
Every few years at GitLab we do seem to get a singlequotes vs doublequotes cop argument crop up, which is why we (thankfully) still don't have any requirement around those. Team doublequotes represent!
Edit: Oh and unrelated to the content of the article, but I really like the design and colour palette of the blog.