4 ms·

I worked at a place with RuboCop as part of the CI, it was a horrible experience. I spent more time fixing lint errors than actual work, and all it does is make

I worked at a place with RuboCop as part of the CI, it was a horrible experience. I spent more time fixing lint errors than actual work, and all it does is make my code less readable.

vishbar 6y ago
Is there not an autoformatter available? We use linting as part of our Python workflow and it works pretty well along with black. There's really not much linting work: just write your code, run black, and it's good to go.
- Xylakant 6y ago
  Rubocop can autoformat the code it complains about.
  - square_usual 6y ago
    Not all cops have autoformatters, though, and some formatters can cause breaking changes.
hrktb 6y ago
If your team as a whole agrees it's less readable you can disable these specific rules. All the project I've seen had specific adjustments to blanket disable some rules (on the top of my head, ` > 0 -> positive?` for instance) and change de defaults of others (e.g. line length) The goal is tailor it to your needs, unlike other linters who have a much more oppiniated and rigid approach on what is supposed to be "right"
zaphirplane 6y ago
One pass of rubocop with autofocus, commit, push Next time just have autocorrect on Save done
JohnBooty 6y ago
Likewise. In our case, we were permitted to disable Rubocop rules at-will via inline comments, which made it slightly bearable, but still onerous considering how slow our CI was (45+ minutes in many cases for a test run) My preferred method is: 1. As a matter of productivity, all coders are expected to have Rubocop enabled in their editor of choice, for the quickest possible feedback loop. 2. Use HoundCI or equivalent to highlight Rubocop complaints in Github's pull request conversation. Then they may become a matter of discussion. Obviously, this only works if the team is mature enough to avoid bikeshedding. 3. Rubocop failures do not, however, cause a hard failure during CI. 4. Haven't set this up yet, but ideally I'd configure things so that perhaps some egregious Rubocop failures (ie, tabs vs. spaces, SQL injection issues, etc) would cause CI failures. Whereas more subjective style issues would simply be flagged for developer attention/discussion. 5. Pull requests to modify the project's .rubocop.yml are always encouraged. Again, culture/maturity come into play here. I've been on teams that bikeshed this sort of thing to death. My current team does not.
adverbly 6y ago
I found it annoying until I added a git hook and got used to auto correcting. Its low friction for me now, and well worth it imo. If you run into a very large number of linting errors then you might naturally write code in an unidiomatic style, which unfortunately takes a while to adjust to.
nathan_f77 6y ago
Yes, RuboCop would be awful if you're only running it as part of the CI build. I've been using RuboCop very heavily for the last few years. I've found it very useful as a solo developer, but it also makes it much easier to work with other developers since we never have to waste time talking about style issues. Here's all the ways I've integrated RuboCop and made it an amazing experience: I use VS Code with the ruby-rubocop extension, and I've enabled the "Format On Save" option. (This uses Prettier for most other file formats.) This would be unbearably slow with vanilla RuboCop, but I get a huge speed boost with rubocop-daemon. (Especially with the bash wrapper script that I wrote [2].) So now every time I save a Ruby file, the file is auto-formatted instantly to correct any warnings. In case it can't automatically fix a warning, I'll still the warning right in my editor, so I can immediately fix it before moving on. The second step is a git hook script in `.git/hooks/commit-msg`. I set this up to run RuboCop for Ruby, plus prettier and eslint for JavaScript. If RuboCop fails with a warning, the script retries with `rubocop -A` to automatically correct any errors. Then I run `git diff` to make sure everything looks good before committing the changes. The final step is to run `rubocop` as part of my CI build, to make sure I didn't miss any warnings (or for any developers who haven't set this up on their machines.) This almost always passes, because the previous two steps usually catch everything first. I disagree with a lot of the default cops, so I just disable lots of them. But I'm pretty happy with my current setup and RuboCop configuration. I totally agree that linters would be awful when you have a very slow feedback loop, and you have to wait anywhere from 10 - 60 minutes before you get a notification for a failed build. But they can be really pleasant experience when the feedback loops are under 100ms and most of the warnings are automatically fixed for you. I now lean on it really heavily, and I've even started to take some shortcuts and save keystrokes, because I know how the auto-formatter will tidy up the code. [1] https://github.com/fohte/rubocop-daemon https://github.com/fohte/rubocop-daemon [2] https://github.com/fohte/rubocop-daemon#more-speed https://github.com/fohte/rubocop-daemon#more-speed
- red2awn 6y ago
  But a formatter can only format auto-fixable code right? I meant lints like high cyclomatic complexity, which requires me to extract out functions pointlessly. I was an intern at that time so didn't make a fuss about changing the config.

I worked at a place with RuboCop as part of the CI, it was a horrible experience. I spent more time fixing lint errors than actual work, and all it does is make my code less readable.

vishbar 6y ago

Is there not an autoformatter available? We use linting as part of our Python workflow and it works pretty well along with black. There's really not much linting work: just write your code, run black, and it's good to go.

Xylakant 6y ago
Rubocop can autoformat the code it complains about.
- square_usual 6y ago
  Not all cops have autoformatters, though, and some formatters can cause breaking changes.

hrktb 6y ago

If your team as a whole agrees it's less readable you can disable these specific rules. All the project I've seen had specific adjustments to blanket disable some rules (on the top of my head, ` > 0 -> positive?` for instance) and change de defaults of others (e.g. line length) The goal is tailor it to your needs, unlike other linters who have a much more oppiniated and rigid approach on what is supposed to be "right"

zaphirplane 6y ago

One pass of rubocop with autofocus, commit, push Next time just have autocorrect on Save done

JohnBooty 6y ago

Likewise. In our case, we were permitted to disable Rubocop rules at-will via inline comments, which made it slightly bearable, but still onerous considering how slow our CI was (45+ minutes in many cases for a test run) My preferred method is: 1. As a matter of productivity, all coders are expected to have Rubocop enabled in their editor of choice, for the quickest possible feedback loop. 2. Use HoundCI or equivalent to highlight Rubocop complaints in Github's pull request conversation. Then they may become a matter of discussion. Obviously, this only works if the team is mature enough to avoid bikeshedding. 3. Rubocop failures do not, however, cause a hard failure during CI. 4. Haven't set this up yet, but ideally I'd configure things so that perhaps some egregious Rubocop failures (ie, tabs vs. spaces, SQL injection issues, etc) would cause CI failures. Whereas more subjective style issues would simply be flagged for developer attention/discussion. 5. Pull requests to modify the project's .rubocop.yml are always encouraged. Again, culture/maturity come into play here. I've been on teams that bikeshed this sort of thing to death. My current team does not.

adverbly 6y ago

I found it annoying until I added a git hook and got used to auto correcting. Its low friction for me now, and well worth it imo. If you run into a very large number of linting errors then you might naturally write code in an unidiomatic style, which unfortunately takes a while to adjust to.

nathan_f77 6y ago

Yes, RuboCop would be awful if you're only running it as part of the CI build. I've been using RuboCop very heavily for the last few years. I've found it very useful as a solo developer, but it also makes it much easier to work with other developers since we never have to waste time talking about style issues. Here's all the ways I've integrated RuboCop and made it an amazing experience: I use VS Code with the ruby-rubocop extension, and I've enabled the "Format On Save" option. (This uses Prettier for most other file formats.) This would be unbearably slow with vanilla RuboCop, but I get a huge speed boost with rubocop-daemon. (Especially with the bash wrapper script that I wrote [2].) So now every time I save a Ruby file, the file is auto-formatted instantly to correct any warnings. In case it can't automatically fix a warning, I'll still the warning right in my editor, so I can immediately fix it before moving on. The second step is a git hook script in `.git/hooks/commit-msg`. I set this up to run RuboCop for Ruby, plus prettier and eslint for JavaScript. If RuboCop fails with a warning, the script retries with `rubocop -A` to automatically correct any errors. Then I run `git diff` to make sure everything looks good before committing the changes. The final step is to run `rubocop` as part of my CI build, to make sure I didn't miss any warnings (or for any developers who haven't set this up on their machines.) This almost always passes, because the previous two steps usually catch everything first. I disagree with a lot of the default cops, so I just disable lots of them. But I'm pretty happy with my current setup and RuboCop configuration. I totally agree that linters would be awful when you have a very slow feedback loop, and you have to wait anywhere from 10 - 60 minutes before you get a notification for a failed build. But they can be really pleasant experience when the feedback loops are under 100ms and most of the warnings are automatically fixed for you. I now lean on it really heavily, and I've even started to take some shortcuts and save keystrokes, because I know how the auto-formatter will tidy up the code. [1] https://github.com/fohte/rubocop-daemon https://github.com/fohte/rubocop-daemon [2] https://github.com/fohte/rubocop-daemon#more-speed https://github.com/fohte/rubocop-daemon#more-speed

red2awn 6y ago
But a formatter can only format auto-fixable code right? I meant lints like high cyclomatic complexity, which requires me to extract out functions pointlessly. I was an intern at that time so didn't make a fuss about changing the config.