Best practices as code using RuboCop
careers.velory.com
Best practices as code using RuboCop
1–10 of 51 posts
Re: Best practices as code using RuboCop
#2I 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
Re: Best practices as code using RuboCop
#3I 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…
Going through the Rubocop configuration ordeal is probably a good investment of time if you have a large codebase where every developer has a different style, and you don't want everyone's code to look completely different.
But most of my Ruby projects are tiny tools with a bus factor of 1. I find "rufo" as a minimal formatter quite nice for those (there are VS Code plugins). For the most part it normalizes '' to "" in code that I might have copied from somewhere else, but doesn't go on to lecture me that "if not" must be written as "unless", and all the other things that the Rails community cares about.
Re: Best practices as code using RuboCop
#4I 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…
I don't understand this complaint – the convention is encoded in the defaults. If you actively choose configuration over convention, it doesn't make much sense to complain that you had to supply configuration!
Re: Best practices as code using RuboCop
#5I 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…
Going through the Rubocop configuration ordeal is probably a good investment of time if you have a large codebase where every developer has a different style, and you don't want everyone's code to look completely different. But most of my Ruby projects are tiny tools with a bus factor of 1. I find "rufo" as a minimal formatter quite nice for those (there are VS Code plugins). For the most part it normalizes '' to ""…
Oooh, I'd not heard of that before, it looks more pep8-ey, rather less bossy -- thanks for the hint.
Re: Best practices as code using RuboCop
#6I 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…
I don't understand this complaint – the convention is encoded in the defaults. If you actively choose configuration over convention, it doesn't make much sense to complain that you had to supply configuration!
I mean: the defaults are so dreadful and wrong that I would have to configure in order to use it; and I don't want to do that.
Re: Best practices as code using RuboCop
#7I 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…
I have similar feelings about pep8's defaults on things that don't matter. It complains about comment formatting. The default 79 character line limit is also pretty unreasonable in 2022, especially when combined with the demand to use spaces instead of tabs.
Re: Best practices as code using RuboCop
#8I 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…
Going through the Rubocop configuration ordeal is probably a good investment of time if you have a large codebase where every developer has a different style, and you don't want everyone's code to look completely different. But most of my Ruby projects are tiny tools with a bus factor of 1. I find "rufo" as a minimal formatter quite nice for those (there are VS Code plugins). For the most part it normalizes '' to ""…
Looks like rufo is looking for maintainers: https://github.com/ruby-formatter/rufo/issues/272
Re: Best practices as code using RuboCop
#9Anyone 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 normal life. In fact the treatment worked so well that after a decade of treatment some people live the rest of their lives without any detectable viral load at all, they are in effect cured of the disease and no longer needed treatment. This is the best practice, as it results in the best outcomes statistically speaking. The life expectancy of HIV/AIDS patients went from a few short months after infection to on par with the general population. This was provable, and not really a matter of serious debate as the evidence is overwhelming.
The formatting of a line of code one way or another feels completely different than that. It feels like somebody with a blog prefers it that way. It really should be called "best preferences" or something.
Re: Best practices as code using RuboCop
#10I 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…
I tried rubocop once, 8 years ago or so, and it saw code like this:
def foo(x)
self.bar = x
end
I never used rubocop again.
(I'm really hoping this was just a rubocop bug, and has since been fixed, but it's enough to ruin your trust.)