RuboCop 0.80: Ruby static code analyzer and code formatter
docs.rubocop.org
RuboCop 0.80: Ruby static code analyzer and code formatter
1–10 of 54 posts
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#2In 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
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#3In 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
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?
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#4In 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
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!)
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#5In 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
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?
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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#6In 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
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?
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#7In 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
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?
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?
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#8In 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
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…
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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#9Earlier quoted context omitted.
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…
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.
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
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#10Earlier quoted context omitted.
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?
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 s…
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.