Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best practices as code using RuboCop

careers.velory.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Best practices as code using RuboCop

#11

Post by ljm »

willcipriano wrote: post #9

Anyone else cringe at the use of "best practices" like this? I can tell you why I do. I first encountered the term 15 years ago or so when studying the medical literature on HIV/AIDS. At the time (might still be this way) the most effective treatment was the now famous "drug cocktail", by applying multiple drugs that were individually only moderately effective we found that HIV/AIDS patients could live a somewhat nor…

Not for the same reason as you, but to me 'best practice' means that you can't do any better. In this context, it's saying that if you do it any other way that this specific way, it's objectively worse.

I prefer 'good practices' or 'guidelines' but as far as something like Rubocop is concerned, I don't really agree that its default setup meets that standard. Without some careful tweaking of the configuration you're likely to end up with a codebase full of premature abstractions that exist for literally no other reason except to satisfy Rubocop.

There is a subset of Rubocop rules that does a much better job, in terms of identifying potential sources of bugs (e.g. calling non-TZ aware date objects) and replacing deprecated methods with their alternatives where possible. The tool is worth it for that, so long as you disable all the nonsense about method lengths, class lengths, number of methods in a class, etc.

Re: Best practices as code using RuboCop

#12

Post by joevandyk »

jjgreen wrote: post #2

I dislike rubocop, not because I dislike linters (pep8 is fine), but because the defaults have strong opinions about things that don't matter if foo? then blah end will result in a complaint about how one should remove the "then". Sure, you can configure rubocop to not make that complaint, and then the next one, and then next one ... but whatever happened to convention-over-configuration? I choose the convention of n…

Using "then" in ruby definitely isn't idiomatic and goes against convention.

Re: Best practices as code using RuboCop

#13

Post by willcipriano »

ljm wrote: post #11
willcipriano wrote: post #9

Anyone else cringe at the use of "best practices" like this? I can tell you why I do. I first encountered the term 15 years ago or so when studying the medical literature on HIV/AIDS. At the time (might still be this way) the most effective treatment was the now famous "drug cocktail", by applying multiple drugs that were individually only moderately effective we found that HIV/AIDS patients could live a somewhat nor…

Not for the same reason as you, but to me 'best practice' means that you can't do any better. In this context, it's saying that if you do it any other way that this specific way , it's objectively worse. I prefer 'good practices' or 'guidelines' but as far as something like Rubocop is concerned, I don't really agree that its default setup meets that standard. Without some careful tweaking of the configuration you're…

> calling non-TZ aware date objects

That's a great example. What if I'm working in a embedded system with limited memory and I need to shave off a few kilobytes? What if time zones don't matter for my implementation, say I make a timer app and the only thing that matters is the delta between two times?

There are things that I think rise close to the level of best practices. For example your password hash comparison function should probably run in constant time, but a linter is never going to pick up on something like that.

Re: Best practices as code using RuboCop

#14

Post by sigzero »

jjgreen wrote: post #2

I dislike rubocop, not because I dislike linters (pep8 is fine), but because the defaults have strong opinions about things that don't matter if foo? then blah end will result in a complaint about how one should remove the "then". Sure, you can configure rubocop to not make that complaint, and then the next one, and then next one ... but whatever happened to convention-over-configuration? I choose the convention of n…

It's right there in their documents about "then" being "bad". Did you just decided "I'll use Rubocop." and not look at what it's conventions were?

Re: Best practices as code using RuboCop

#15

Post by aniforprez »

Is there a tool for ruby that is actually opinionated and doesn't have a sea of configuration options? Rubocop just has WAY too many options and configuration going on. Tools for other languages like black/flake8 and govet are quite opinionated and these prevent bikeshedding. A lot of the rules as has been mentioned by others on this thread don't properly analyze the code resulting in bugs when you follow their recommendations. I'm not sure if Rubocop does an AST analysis or does it properly cause I've had a similar experience

Re: Best practices as code using RuboCop

#16

Post by jjgreen »

sigzero wrote: post #14
jjgreen wrote: post #2

I dislike rubocop, not because I dislike linters (pep8 is fine), but because the defaults have strong opinions about things that don't matter if foo? then blah end will result in a complaint about how one should remove the "then". Sure, you can configure rubocop to not make that complaint, and then the next one, and then next one ... but whatever happened to convention-over-configuration? I choose the convention of n…

It's right there in their documents about "then" being "bad". Did you just decided "I'll use Rubocop." and not look at what it's conventions were?

No, this first came up at a place I worked, someone suggested using it, we evaluated it, this was one of the things that annoyed me, because it doesn't matter. After quite a bit of time discussing and configuring it we decided not to proceed. From time-to-time I'll look at it again, but it seems to get more bossy as time goes by.

Re: Best practices as code using RuboCop

#17

Post by jstan65536 »

A lot about the Rubocop philosophy really grates on me. Many of its preferences are arbitrary and don't, in my opinion, contribute to code readability. Many others are good as a rule of thumb but cause more harm than good when they are blindly enforced by a robot. A recent example from my work went something like this:

  if some_verbose_condition && some_other_verbose_condition
    do_the_thing unless excluded_case || other_excluded_case
  end
Rubocop changed this to

  if (some_verbose_condition && some_other_verbose_condition) && !(excluded_case || other_excluded_case)
    do_the_thing
  end
which is just worse

and then it had the gall to complain that the line containing the `if` was too long.

That said, if you disable half its rules, Rubocop can be a useful tool. We've long had a list of database migration best practices, which we've built up over the years to ensure changes to our application's database schema don't cause downtime or other issues. Lately I've been writing cops to automate checks against these practices.

Useful feedback: "Heads up: changing the type of that column is going to lock the users table and bring the site down; see $BEST_PRACTICES_DOCUMENT"

Not useful feedback: "zomg ur cyclomatic complexity si 2 high!!1"

Re: Best practices as code using RuboCop

#18

Post by jstan65536 »

aniforprez wrote: post #15

Is there a tool for ruby that is actually opinionated and doesn't have a sea of configuration options? Rubocop just has WAY too many options and configuration going on. Tools for other languages like black/flake8 and govet are quite opinionated and these prevent bikeshedding. A lot of the rules as has been mentioned by others on this thread don't properly analyze the code resulting in bugs when you follow their recom…

You should have a look at Standard Ruby https://github.com/testdouble/standard

In particular, a lot from the lightning talk resonates with me.

Re: Best practices as code using RuboCop

#20

Post by aniforprez »

jstan65536 wrote: post #18
aniforprez wrote: post #15

Is there a tool for ruby that is actually opinionated and doesn't have a sea of configuration options? Rubocop just has WAY too many options and configuration going on. Tools for other languages like black/flake8 and govet are quite opinionated and these prevent bikeshedding. A lot of the rules as has been mentioned by others on this thread don't properly analyze the code resulting in bugs when you follow their recom…

You should have a look at Standard Ruby https://github.com/testdouble/standard In particular, a lot from the lightning talk resonates with me.

It seems to use rubocop under the hood but enforces no configuration. Yeah that looks like something I can use
Post reply on HN