If the author is here, your text has no padding on mobile. Using an iPhone 12
Best practices as code using RuboCop
21–30 of 51 posts
Re: Best practices as code using RuboCop
#22Anyone 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…
"Best practice" in software, near as I can tell, means "what you will not get fired for doing". It means adhering to rules that the community has adopted, irrespective of whether those rules are a good idea even in the general case, let alone a specific instance where it might be better to contravene conventional wisdom.
Re: Best practices as code using RuboCop
#23Earlier quoted context omitted.
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.
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.)
Re: Best practices as code using RuboCop
#24What's wrong with using `let`?
Re: Best practices as code using RuboCop
#25A 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!
Re: Best practices as code using RuboCop
#26What's wrong with using `let`?
[deleted]
Re: Best practices as code using RuboCop
#27A 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.
Re: Best practices as code using RuboCop
#28What's wrong with using `let`?
Some discussion here: https://github.com/rubocop/rubocop-rspec/issues/94
Re: Best practices as code using RuboCop
#29Earlier quoted context omitted.
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.
> because it doesn't matter
But, if it doesn't matter, why not let RuboCop make all `if`s consistent with `rubocop --auto-fix` and be done with it, instead of configuring RuboCop to not complain about it?
It seemed that this style choice did, in fact, matter a bit. At least enough to make you change RuboCop's defaults to accommodate to it. And that's fine; that's why those things are configurable :)
Of course, it's also fine to decide not to use RuboCop if you need to reconfigure a lot of it's defaults. Fighting with our own tools doesn't make any sense, but for some reason it's not an uncommon thing to do in this industry.
Re: Best practices as code using RuboCop
#30What's wrong with using `let`?
I personally am ambivalent about it, but the argument against let is generally about keeping as much of the context of your tests inside it. The error message of the cop in TFA alludes to this when it recommends using the four phase pattern (setup/exercise/verify/teardown). That way, you can almost look at a test in isolation and understand everything about it, which may not be true for a complex let.