6 ms·

In my opinion RuboCop is too strict. Every code standard analyzer takes some tweaking to get it set up for a particular project and team standards, but RuboCop

In my opinion RuboCop is too strict. Every code standard analyzer takes some tweaking to get it set up for a particular project and team standards, but RuboCop needs changing of a ton of rules to make it even usable in a reasonable fashion. I love it because it brings some order to a meta-everything world, but it'd be nice if it came with a reasonable set of rules by default

predators372 7y ago
What are some pain points in your experience? You don't have to be super specific but I'm just curious what parts get in your way when you use it with standard config?
- codebeaker 7y ago
  I'd say that in our environment we introduced Rubocop into a 4 year old Ruby project that started on Ruby 1.9 and is now on 2.5, our code has a lot of warts. We run rubocop (including a handful of our own custom cops for enforcing US-english spelling, and some specific "remember to use a transaction here") only on changed files (using codeclimate) That means as we gradually touch more and more of our older code, we slowly enforce the styleguide. We don't run a lot of custom configs globally (none, I think) and disable selective overzealous cops on specific lines, or blocks. Some notable annoyances are `def Something()` which is named this way to model it after the coercions in Kernel, which rubocop complains about because of the pascal casing, and a couple of cases of too-long-lines in long, long, long doubles/mocks in rspec specs, which is a separate problem of its own.
  - abaldwin7302 7y ago
    One option that's worked well for us was using rubocop's `--auto-gen-config`. This creates a specific ignore/TODO list on a per file basis.
- wyuenho 7y ago
  I'm fairly new to Ruby after having many years of Python and JS experience. One of the most annoying things I find with Rubocop is it asks me to break every 5-10 lines or so into a separate method by default. I mean, Ruby is not a particularly verbose language, so I don't understand why a linter will encourage people to break non-reusable details that are only a couple of lines long into separate methods. I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all? Do Rubyist really write code like this as a second nature?
  - yebyen 7y ago
    I would ask if you're doing Ruby, or object oriented design? Because the first rule of SOLID is Single-Responsibility, and there is this great concept frequently repeated in the OO design circles of Ruby conference talks, "I just want to send a method to an object." I can't say for sure that your method longer than 5 lines is breaking this rule, but if I was a betting man, I'd bet it's breaking one of those rules. Check out sandi-meter, something much simpler than Rubocop, but also includes this rule about 5 lines method length limit. Maybe you know Sandi Metz, and if you do, maybe you haven't heard of the "Sandi Metz Rules" from POODR; rule number two is "more than 5 lines" – my favorite rule is "controllers with more than one instance variable." https://github.com/makaroni4/sandi_meter https://github.com/makaroni4/sandi_meter The great thing about this tool as opposed to RuboCop is that one thing should be really clear when you start using it on an existing code project... the way to interpret the big red spot on your chart is NOT that you should go out and change those things immediately to conform to the new rules. I understand why you want one instance variable per controller, as the job of a controller is really straightforward, if it only exposes a RESTful interface to a single class of objects, but the more specialized features and bolt-ons it accumulates, the less straightforward it will be to understand and refactor the controller code. But when you're taking an existing controller and adding a new feature to it, the right abstraction to use is probably not obvious until you've spent some time with the idea of the feature, maybe tried out a few different implementations. For a lot of this stuff, when it clicks, you get it, but before then it seems like these rules have no purpose and it doesn't benefit you to follow them blindly. It pays to know when a rule is important, and when you can safely ignore it. So, what I would say in response to your question is that simply breaking the method in two is not necessarily the refactor that is suggested by the rules of OO design. You should go back to the principles and try to figure out why that method is longer than 5 lines, and what else about the class has resulted in methods that are so long; is it related to having broken one of the more fundamental rules of design, and is it likely to present an obstacle to later change? (Or is this method never likely to change, and you should just ignore it because... it's fine! This is often the answer.) Maybe you wrote this method to honor some complicated scheme of ideas, that are really separate ideas, and maybe they should be extracted into separate classes so that it's easier to validate changes to the ideas when it's time to change those business rules. (Or, maybe none of that is true, and they should really be kept in one place because how else are you going to understand all the rules and interactions between them, than by having them together) – Chances are good, though, that the code has broken one of the more fundamental rules, like Open/Closed or Dependency Inversion, and that there is a way to make the method simpler without compromising readability. Maybe there are some heavy calculations that are done inside of the method, and it would be better for DRY to extract them into another method that has a descriptive name, and simply lives nearby. POODR is a great read I'm told; Refactoring is also an important reference work, and if it's too dry for direct consumption, there are great adaptations that will help get you up to speed on code smells and remediation strategies like https://refactoring.guru https://refactoring.guru
yebyen 7y ago
The thing about that is, what's reasonable for you and your team is not always reasonable for me and my team. Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen. Most of the members of my team don't use this font, or even the same terminal, so I think that a 110 character limit is a good compromise, ...but I don't work alone, and so if we're going to set a standard, it should be a discussion and we should all have input before it's agreed to. On the other hand you have tools like Rufo (or prettier, or gofmt) where these kinds of discussions are considered as wasteful and inviting unnecessary conflict about the color of the bike shed. There's a strong argument to be made that there is a reasonable default for standards, and it follows that we all should use the same standards as everyone else, and be glad that there's only one standard to worry about! Rubocop is a much bigger tool than Rufo. I am glad, personally, that the developers of these tools talk to each other, and in some cases they have made efforts to make sure the defaults of both tools do not step on each other, which would make it impossible to use the two slightly orthogonal tools together on the same project. (I hope my team will find the means to adopt one or both of these tools soon!)
- londt8 7y ago
  I get your point, but i think the main reason for using 80 character line length nowadays is that its more readable. Books use often line lenght of about 60 characters for this reason.
  - yebyen 7y ago
    That's fine, when it is more readable... but there is a convention in Ruby of making your classes and method names as descriptively as possible, not even ruling out the possibility that they might be very nearly full sentences. I am in strong agreement that there should be a character limit, and I'm even convinced that my 180 character wide terminal is longer than what would be an appropriate limit. But 80 characters is less than half of that, and so I'm not convinced that honoring a default 80 character limit is going to make anything more readable, more likely that it will just result in me turning up my font size so there is not so much unused space on my screen. I think it's also true that most people use a larger than 80 character wide terminal today. I guess the point is, without getting hung up on this knob in particular, that fewer knobs is pretty much always better; at least that was the central theme of the issue where I got the idea that Rufo maintainer team has this outlook: https://github.com/ruby-formatter/rufo/issues/2 https://github.com/ruby-formatter/rufo/issues/2
phaedryx 7y ago
Every RuboCop rule is reasonable. That is, you can look up the reason and see if you agree or not. Our team has overridden about a dozen rules (we bumped up line length and class length), but I find most of the default rules are fine. Out of curiosity, what rules are unreasonable to you?
- nimblegorilla 7y ago
  In my opinion the rules about requiring or forbidding parentheses are fairly arbitrary. Sometimes it's really nice to fit three panes of code on a single laptop screen. Long lines can also indicate a code smell. It's ironic that one of the first things most teams change is the 80 character line length.
- chrisseaton 7y ago
  Some rules break Ruby semantics - if you apply their 'rule' you get a program that does something different! I think that's an unreasonable rule.
- hartator 7y ago
  ‘private’ methods forced to be NOT indented.
- 22c 7y ago
  Not every rule has a reason, some of it is just "because style guide" and if you try to look up the rationale there, you'll find none. Classic example is Perl style %w(literal arrays) vs ['traditional', 'arrays']. > Prefer `%w` to the literal array syntax when you need an array of strings Which was introduced[1] into the style guide nearly 9 years ago with practically no reasoning. Prefer `%w` because why exactly? [1] https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff1b2ca6ee7502bb0c53afec4f25ae154a19 https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff...
  - hirundo 7y ago
    I prefer the brackets to parens because it makes it more clear at a glance that the result is an array.
existentialmutt 7y ago
This has been my experience too. Fortunately rubocop makes it easy to distribute alternate settings as gems. I use https://github.com/sider/meowcop https://github.com/sider/meowcop as a reasonable base setting. It's more relaxed about style and makes rubocop more of a linter, which is what I want.
schmijos 7y ago
This is exactly nice about it. With Rubocop standardrb (https://github.com/testdouble/standard https://github.com/testdouble/standard) has a solid foundation to make everyone's live easy.
bozhidar 7y ago
RuboCop's author here. On the subject of the defaults - it's extremely hard to come up with something that everyone agrees on. Originally RuboCop didn't have any config options and tried to be something like gofmt, prettier (not that it exist back then), etc, but soon we realized that Ruby has been around for way too long and there are way too many competing coding styles in circulations. Therefore our current approach - support every popular coding style, optimize by default for the community style guide (https://rubystyle.guide/ https://rubystyle.guide/). When it comes to style I think the most important thing is consistency and everything else is secondary to that. More on the subject - https://rubystyle.guide/#a-note-about-consistency https://rubystyle.guide/#a-note-about-consistency

predators372 7y ago

What are some pain points in your experience? You don't have to be super specific but I'm just curious what parts get in your way when you use it with standard config?

codebeaker 7y ago
I'd say that in our environment we introduced Rubocop into a 4 year old Ruby project that started on Ruby 1.9 and is now on 2.5, our code has a lot of warts. We run rubocop (including a handful of our own custom cops for enforcing US-english spelling, and some specific "remember to use a transaction here") only on changed files (using codeclimate) That means as we gradually touch more and more of our older code, we slowly enforce the styleguide. We don't run a lot of custom configs globally (none, I think) and disable selective overzealous cops on specific lines, or blocks. Some notable annoyances are `def Something()` which is named this way to model it after the coercions in Kernel, which rubocop complains about because of the pascal casing, and a couple of cases of too-long-lines in long, long, long doubles/mocks in rspec specs, which is a separate problem of its own.
- abaldwin7302 7y ago
  One option that's worked well for us was using rubocop's `--auto-gen-config`. This creates a specific ignore/TODO list on a per file basis.
wyuenho 7y ago
I'm fairly new to Ruby after having many years of Python and JS experience. One of the most annoying things I find with Rubocop is it asks me to break every 5-10 lines or so into a separate method by default. I mean, Ruby is not a particularly verbose language, so I don't understand why a linter will encourage people to break non-reusable details that are only a couple of lines long into separate methods. I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all? Do Rubyist really write code like this as a second nature?
- yebyen 7y ago
  I would ask if you're doing Ruby, or object oriented design? Because the first rule of SOLID is Single-Responsibility, and there is this great concept frequently repeated in the OO design circles of Ruby conference talks, "I just want to send a method to an object." I can't say for sure that your method longer than 5 lines is breaking this rule, but if I was a betting man, I'd bet it's breaking one of those rules. Check out sandi-meter, something much simpler than Rubocop, but also includes this rule about 5 lines method length limit. Maybe you know Sandi Metz, and if you do, maybe you haven't heard of the "Sandi Metz Rules" from POODR; rule number two is "more than 5 lines" – my favorite rule is "controllers with more than one instance variable." https://github.com/makaroni4/sandi_meter https://github.com/makaroni4/sandi_meter The great thing about this tool as opposed to RuboCop is that one thing should be really clear when you start using it on an existing code project... the way to interpret the big red spot on your chart is NOT that you should go out and change those things immediately to conform to the new rules. I understand why you want one instance variable per controller, as the job of a controller is really straightforward, if it only exposes a RESTful interface to a single class of objects, but the more specialized features and bolt-ons it accumulates, the less straightforward it will be to understand and refactor the controller code. But when you're taking an existing controller and adding a new feature to it, the right abstraction to use is probably not obvious until you've spent some time with the idea of the feature, maybe tried out a few different implementations. For a lot of this stuff, when it clicks, you get it, but before then it seems like these rules have no purpose and it doesn't benefit you to follow them blindly. It pays to know when a rule is important, and when you can safely ignore it. So, what I would say in response to your question is that simply breaking the method in two is not necessarily the refactor that is suggested by the rules of OO design. You should go back to the principles and try to figure out why that method is longer than 5 lines, and what else about the class has resulted in methods that are so long; is it related to having broken one of the more fundamental rules of design, and is it likely to present an obstacle to later change? (Or is this method never likely to change, and you should just ignore it because... it's fine! This is often the answer.) Maybe you wrote this method to honor some complicated scheme of ideas, that are really separate ideas, and maybe they should be extracted into separate classes so that it's easier to validate changes to the ideas when it's time to change those business rules. (Or, maybe none of that is true, and they should really be kept in one place because how else are you going to understand all the rules and interactions between them, than by having them together) – Chances are good, though, that the code has broken one of the more fundamental rules, like Open/Closed or Dependency Inversion, and that there is a way to make the method simpler without compromising readability. Maybe there are some heavy calculations that are done inside of the method, and it would be better for DRY to extract them into another method that has a descriptive name, and simply lives nearby. POODR is a great read I'm told; Refactoring is also an important reference work, and if it's too dry for direct consumption, there are great adaptations that will help get you up to speed on code smells and remediation strategies like https://refactoring.guru https://refactoring.guru

yebyen 7y ago

The thing about that is, what's reasonable for you and your team is not always reasonable for me and my team. Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen. Most of the members of my team don't use this font, or even the same terminal, so I think that a 110 character limit is a good compromise, ...but I don't work alone, and so if we're going to set a standard, it should be a discussion and we should all have input before it's agreed to. On the other hand you have tools like Rufo (or prettier, or gofmt) where these kinds of discussions are considered as wasteful and inviting unnecessary conflict about the color of the bike shed. There's a strong argument to be made that there is a reasonable default for standards, and it follows that we all should use the same standards as everyone else, and be glad that there's only one standard to worry about! Rubocop is a much bigger tool than Rufo. I am glad, personally, that the developers of these tools talk to each other, and in some cases they have made efforts to make sure the defaults of both tools do not step on each other, which would make it impossible to use the two slightly orthogonal tools together on the same project. (I hope my team will find the means to adopt one or both of these tools soon!)

londt8 7y ago
I get your point, but i think the main reason for using 80 character line length nowadays is that its more readable. Books use often line lenght of about 60 characters for this reason.
- yebyen 7y ago
  That's fine, when it is more readable... but there is a convention in Ruby of making your classes and method names as descriptively as possible, not even ruling out the possibility that they might be very nearly full sentences. I am in strong agreement that there should be a character limit, and I'm even convinced that my 180 character wide terminal is longer than what would be an appropriate limit. But 80 characters is less than half of that, and so I'm not convinced that honoring a default 80 character limit is going to make anything more readable, more likely that it will just result in me turning up my font size so there is not so much unused space on my screen. I think it's also true that most people use a larger than 80 character wide terminal today. I guess the point is, without getting hung up on this knob in particular, that fewer knobs is pretty much always better; at least that was the central theme of the issue where I got the idea that Rufo maintainer team has this outlook: https://github.com/ruby-formatter/rufo/issues/2 https://github.com/ruby-formatter/rufo/issues/2

phaedryx 7y ago

Every RuboCop rule is reasonable. That is, you can look up the reason and see if you agree or not. Our team has overridden about a dozen rules (we bumped up line length and class length), but I find most of the default rules are fine. Out of curiosity, what rules are unreasonable to you?

nimblegorilla 7y ago
In my opinion the rules about requiring or forbidding parentheses are fairly arbitrary. Sometimes it's really nice to fit three panes of code on a single laptop screen. Long lines can also indicate a code smell. It's ironic that one of the first things most teams change is the 80 character line length.
chrisseaton 7y ago
Some rules break Ruby semantics - if you apply their 'rule' you get a program that does something different! I think that's an unreasonable rule.
hartator 7y ago
‘private’ methods forced to be NOT indented.
22c 7y ago
Not every rule has a reason, some of it is just "because style guide" and if you try to look up the rationale there, you'll find none. Classic example is Perl style %w(literal arrays) vs ['traditional', 'arrays']. > Prefer `%w` to the literal array syntax when you need an array of strings Which was introduced[1] into the style guide nearly 9 years ago with practically no reasoning. Prefer `%w` because why exactly? [1] https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff1b2ca6ee7502bb0c53afec4f25ae154a19 https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff...
- hirundo 7y ago
  I prefer the brackets to parens because it makes it more clear at a glance that the result is an array.

existentialmutt 7y ago

This has been my experience too. Fortunately rubocop makes it easy to distribute alternate settings as gems. I use https://github.com/sider/meowcop https://github.com/sider/meowcop as a reasonable base setting. It's more relaxed about style and makes rubocop more of a linter, which is what I want.

schmijos 7y ago

This is exactly nice about it. With Rubocop standardrb (https://github.com/testdouble/standard https://github.com/testdouble/standard) has a solid foundation to make everyone's live easy.

bozhidar 7y ago

RuboCop's author here. On the subject of the defaults - it's extremely hard to come up with something that everyone agrees on. Originally RuboCop didn't have any config options and tried to be something like gofmt, prettier (not that it exist back then), etc, but soon we realized that Ruby has been around for way too long and there are way too many competing coding styles in circulations. Therefore our current approach - support every popular coding style, optimize by default for the community style guide (https://rubystyle.guide/ https://rubystyle.guide/). When it comes to style I think the most important thing is consistency and everything else is secondary to that. More on the subject - https://rubystyle.guide/#a-note-about-consistency https://rubystyle.guide/#a-note-about-consistency