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

31–40 of 51 posts

Re: Best practices as code using RuboCop

#31

Post by brightstep »

jstan65536 wrote: post #17

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 || othe…

I don't like either of your or rubocop's approach. If you have that many conditionals, bind a local variable that describes the condition being checked. Then you have an easy to read `if` with a single variable.

Re: Best practices as code using RuboCop

#32

Post by ngcazz »

r-s wrote: post #28
henryaj wrote: post #24

What's wrong with using `let`?

Some discussion here: https://github.com/rubocop/rubocop-rspec/issues/94

Using `let` carries the risk of increasing the cognitive load required to understand why a test is failing or passing if it's not used carefully.

- they bring example execution order into play, especially with nested contexts and nested `let`s shadowing other above.

- they invite DRYing up test code, making it really easy to couple unrelated tests together and hard to understand tests in isolation.

- the corollary to the above is creating a brittle test suite. (in any case if DRY is a footgun in production code, it's doubly so in test code.)

- they require you to divert your attention from the examples to see what the states of your test objects are going to be.

These pitfalls can be avoided if, for example, you favor building up your test object graphs inside your examples.

(@r-s That's not the same thing though, they're talking about the eagerly evaluated version of `let`.)

Re: Best practices as code using RuboCop

#33

Post by jjgreen »

wrs wrote: post #23
jjgreen wrote: post #16

Earlier quoted context omitted.

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.

Enforcing consistent choices for things that don’t matter is most of the value of a code style linter. In fact “things that don’t matter” is not a bad definition of “code style”. (BTW, “then” on a multiline “if” is definitely outside mainstream Ruby style, based on my decade of experience...this is not one of Rubocop’s controversial defaults.)

I'm not sure I agree, code style is (or should) be about things like method length, naming conventions, iteration styles ... those do matter and should be in the scope of a linter. The presence of the word "then" which makes no difference to the resulting bytecode but does make the code more readable (IMHO) is not.

(BTW, I've seen "then"s aplenty in my decade-and-a-bit of Ruby experience, possibly this is a geographical thing, like the SF no-parentheses-in-methods thing)

Re: Best practices as code using RuboCop

#34

Post by [deleted] »

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…

[deleted]

Re: Best practices as code using RuboCop

#35

Post by LanceH »

d3nj4l wrote: post #27
jstan65536 wrote: post #17

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 || othe…

I don't know, your version in the example looks pretty bad to me? Sure, maybe the excessive line length of the combined if is a readability issue, but something about a postfix unless inside an if makes it very hard to follow what combination of flags would trigger it. In this scenario, I'd try to give meaningful names to the boolean expressions, and write a simpler conditional.

do_some_thing if ready_to_go(variables_needed_for_conditionals...)

Re: Best practices as code using RuboCop

#36

Post by engineeringmtm »

It can be brutal to use rubocop in an old project. Here is how we did it.

We only lint the files that changed after the date we integrated rubocop : `git -c log.showRoot=false log --no-merges --pretty=format: --name-only --since="2022-01-01"`

Then we heavily customized `.rubocop.yml` to avoid the rules that were not auto-correctable.

It was still brutal for a couple of weeks but now, maybe 2 years later, everything is fine.

Re: Best practices as code using RuboCop

#37

Post by ch4s3 »

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…

I agree that "best practices" probably isn't the best name for what community linters are and do, but "loose consensus among some OSS contributors is that these are agreeable convention" is a bit wordy. I don't think people generally take it literally.

Re: Best practices as code using RuboCop

#38

Post by shepherdjerred »

I much prefer the tool Prettier. Any aesthetic styling of code should be unconfigurable so that teams using the tool don't waste time arguing about using tabs or spaces.

Prettier does a fantastic job of this for many languages. RuboCop is of course still useful for catching things that impact logic/functionality/performance (e.g. the issue presented in the article), but it's not a great choice for enforcing code formatting since it is far too configurable.

Re: Best practices as code using RuboCop

#39

Post by jaredsohn »

brightstep wrote: post #31
jstan65536 wrote: post #17

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 || othe…

I don't like either of your or rubocop's approach. If you have that many conditionals, bind a local variable that describes the condition being checked. Then you have an easy to read `if` with a single variable.

or a model method or private method in the class containing this code

Re: Best practices as code using RuboCop

#40

Post by jaredsohn »

quesera wrote: post #25
jstan65536 wrote: post #17

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 || othe…

> We've long had a list of database migration best practices > ... > Lately I've been writing cops to automate checks against these practices. These would be great to share and popularize. Too many Rails shops do this badly!

There is already https://github.com/ankane/strong_migrations
Post reply on HN