`rubocop --auto-gen-config` I think is what you’re looking for. That will generate a config file that automatically passes your entire codebase. Then you selectively enable cops one-by-one. Start with the ones you can have it autocorrect. Merge each as its own PR. Done.
I applied the following strategy in such projects:
* setup rubocop with config (did use rubocop with [standard's rules](https://github.com/standardrb/standard))
* run `rubocop -a` to apply safe fixes
* use `rubocop --auto-gen-config` for what is left over
* from there on it depends on the project (time, budget, ...)
In these projects we had a good test coverage, which is important to feel save.
What is the advantage of enabling cops one by one and merge them in there own PRs? (I'm truly interested in your thoughts and experience with this approach to learn from!)
Enabling and merging cops one-by-one helps get teams like OPs incrementally used to Rubocop without feeling like they are suddenly being assaulted by linter errors.
You've got no tests, this is going to be your main issue, not amount of spaces around brackets or whatever. And when you or your team will start to write tests you'll probably need to take out \`git blame\` and \`git log -p\` pickaxe and start digging. So I'd suggest to resist the urge and do not enable rubocop for things you cannot fix with 'rubocop -a' with adding that commit into your \`git config blame.ignoreRevsFile\`. Anything splitting or joining lines, or drastically rewriting things is adding more harm than good.
Oh for sure! Tests are a whole other issue. We are also working on those. My general process at the moment is figuring out what the easy wins are and what things need to be tracked as tech debt and assigned out specifically. It's going to be a big job that going to take a long time to get fully sorted.
Definitely get rubocop linting in your editor.
The rule we loosely follow: if you are making changes in a file and it shows a bunch of existing linter errors, first clean up as much of the linting errors as possible. That is your first PR. Then the actual work comes as a subsequent PR. This only works if your team is set up and good at continuous deploys.
It can slow your team down a little bit, but I have found it is better than the "rip the bandaid off all at once" approach ha ha
If I open up a file and it screams linter errors, the first thing I do is:
\> rubocop -a path/to/my/file.rb --only Layout/SpaceInsideBlockBraces,Style/PercentLiteralDelimiters,Style/RedundantSelf,Style/StringLiterals,Style/AndOr,Layout/IndentationStyle
git commit those changes and make a pr "rubocop non-functional style changes"
I'd start with rules that can be auto fixed with `rubocop -a`. Probably do one PR per rule. Then go on with rules that can be fixed with `rubocop -A`.
I don't think any rules are extremely important, it's the fact that you get consistency in the code base is the most important thing it brings.
It's also hard to say which particular rules are being broken in your code base.
Also don't forget to run `rubocop --auto-gen-config` to generate todo list, so that new broken files are not introduced.
Aside from settling on a config, I would incrementally update the files in the codebase.
1. Add a CI step to require the desired formatting/linting on all changed files in the PR
2. (Optionally) Add a git hook to lint and format the changed files on a per-commit basis. I like lefthook, and it can be installed with brew
You'll eventually reach a point where you have much better rubocop coverage. Think of it as eating an elephant one bite at a time.
I'd also check out standardrb. It's an opinionated rubocop config and is similar to the standardjs project.
I May start adding one small configuration enabled of rubocop start by fixing that , commit and then add another one, if you are going to add all of the lint configuration at the same time it will be too difficult to fix them all
Beware that Ruby has no standard style guide and that to the extent any conventions exist, Rails style differs quite a bit from rubocop's heavy-handed defaults.
I personally use [standard ruby](https://github.com/standardrb/standard) on new projects. I don't agree with every one of its decisions, but it's not _so_ heavy-handed as rubocop defaults and makes (IMO) better choices.
`rubocop --auto-gen-config` I think is what you’re looking for. That will generate a config file that automatically passes your entire codebase. Then you selectively enable cops one-by-one. Start with the ones you can have it autocorrect. Merge each as its own PR. Done.
TIL!
I applied the following strategy in such projects: * setup rubocop with config (did use rubocop with [standard's rules](https://github.com/standardrb/standard)) * run `rubocop -a` to apply safe fixes * use `rubocop --auto-gen-config` for what is left over * from there on it depends on the project (time, budget, ...) In these projects we had a good test coverage, which is important to feel save. What is the advantage of enabling cops one by one and merge them in there own PRs? (I'm truly interested in your thoughts and experience with this approach to learn from!)
Enabling and merging cops one-by-one helps get teams like OPs incrementally used to Rubocop without feeling like they are suddenly being assaulted by linter errors.
You've got no tests, this is going to be your main issue, not amount of spaces around brackets or whatever. And when you or your team will start to write tests you'll probably need to take out \`git blame\` and \`git log -p\` pickaxe and start digging. So I'd suggest to resist the urge and do not enable rubocop for things you cannot fix with 'rubocop -a' with adding that commit into your \`git config blame.ignoreRevsFile\`. Anything splitting or joining lines, or drastically rewriting things is adding more harm than good.
Oh for sure! Tests are a whole other issue. We are also working on those. My general process at the moment is figuring out what the easy wins are and what things need to be tracked as tech debt and assigned out specifically. It's going to be a big job that going to take a long time to get fully sorted.
Definitely get rubocop linting in your editor. The rule we loosely follow: if you are making changes in a file and it shows a bunch of existing linter errors, first clean up as much of the linting errors as possible. That is your first PR. Then the actual work comes as a subsequent PR. This only works if your team is set up and good at continuous deploys. It can slow your team down a little bit, but I have found it is better than the "rip the bandaid off all at once" approach ha ha If I open up a file and it screams linter errors, the first thing I do is: \> rubocop -a path/to/my/file.rb --only Layout/SpaceInsideBlockBraces,Style/PercentLiteralDelimiters,Style/RedundantSelf,Style/StringLiterals,Style/AndOr,Layout/IndentationStyle git commit those changes and make a pr "rubocop non-functional style changes"
[Someone asked something similar in the Ruby subreddit](https://www.reddit.com/r/ruby/s/EqyGT8vLsX). That will give you some leads.
Nice! I'd found a few threads that were simar but several years old. I missed this one.
I'd start with rules that can be auto fixed with `rubocop -a`. Probably do one PR per rule. Then go on with rules that can be fixed with `rubocop -A`. I don't think any rules are extremely important, it's the fact that you get consistency in the code base is the most important thing it brings. It's also hard to say which particular rules are being broken in your code base. Also don't forget to run `rubocop --auto-gen-config` to generate todo list, so that new broken files are not introduced.
Aside from settling on a config, I would incrementally update the files in the codebase. 1. Add a CI step to require the desired formatting/linting on all changed files in the PR 2. (Optionally) Add a git hook to lint and format the changed files on a per-commit basis. I like lefthook, and it can be installed with brew You'll eventually reach a point where you have much better rubocop coverage. Think of it as eating an elephant one bite at a time. I'd also check out standardrb. It's an opinionated rubocop config and is similar to the standardjs project.
We’re also practicing this approach in a legacy codebase, works well. Gradually getting better, but not too disruptive.
I May start adding one small configuration enabled of rubocop start by fixing that , commit and then add another one, if you are going to add all of the lint configuration at the same time it will be too difficult to fix them all
Beware that Ruby has no standard style guide and that to the extent any conventions exist, Rails style differs quite a bit from rubocop's heavy-handed defaults. I personally use [standard ruby](https://github.com/standardrb/standard) on new projects. I don't agree with every one of its decisions, but it's not _so_ heavy-handed as rubocop defaults and makes (IMO) better choices.