[HN Gopher] Rubocop-obsession: RuboCop extension focused on high...
___________________________________________________________________
Rubocop-obsession: RuboCop extension focused on higher-level
concepts
Author : thunderbong
Score : 44 points
Date : 2024-10-28 05:59 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| henning wrote:
| The world runs on code that violates some or all of these rules.
| Following them won't fix any of the problems they have. It
| doesn't matter.
| hrdwdmrbl wrote:
| It does help at some margin to make code more readable. Humans
| just aren't that great at reading and understanding code. It
| has been said: "Write for humans, not computers because
| computers will understand what you wrote no matter how badly
| written". So if you're writing code on a team, do your co-
| workers and your future-self a favour and write code that's
| easy to read. It won't run any better or with fewer bugs, but
| it will be easier to understand later, easier to be understood
| by others, and "wishful thinking here": easier to debug.
| xtracto wrote:
| One of the things i miss the most from developing in ruby is the
| code quality instrumentation: metric-fu, reek, rubocop and lots
| of other gems that allowed us (in a previous ruby shop)
| understand and monitor the quality of our code like ABC,
| Cyclomatic complexity, duplicated code, etc).
|
| Now in Typescript, I haven't found a lot of tools to
| calculate,visualize and track these stats. Metric-fu was amazing.
| Alifatisk wrote:
| Don't forget about Brakeman!
| MrJohz wrote:
| You can get a lot of mileage out of ESLint + typescript-ESLint
| + various other plugins. It's more of a "choose your own
| adventure" kind of experience, but the defaults are a good
| start, and if you're looking for cyclomatic complexity and all
| that jazz, there's various plugins that can calculate that. And
| the typescript ESLint plugin is great because it uses the types
| as part of the hints, which is great for finding places where
| you no longer need optional chaining, or where a condition is
| always true/false because you forgot what types things were.
|
| That said, I tend to take a much more lean approach to linting
| these days. I try to only include lints that are actionable,
| likely to lead to real bugs, and have no false positives.
| Everything else feels like it's better handled in code review.
| If you don't know why your function is too complex and
| difficult to read, I don't want you to rewrite it just to
| satisfy a robot that's following arbitrary rules! I want to be
| able to have a discussion with you about proper techniques for
| splitting apart code.
|
| But there's definitely people who go the other way entirely and
| build incredibly strict ESLint configurations, so looking for
| those might help you if that's what you want.
| Alifatisk wrote:
| I'm getting this right away!
| codesnik wrote:
| Nice. Now we can probably ask to move there half of the too nosy
| rubocop rules from the main rubocop repo. And then to never
| install rubocop-obsession!
| bioneuralnet wrote:
| Right? I seem to be the only high-level SWE at my company who
| hates RuboCop. Some of it's fine (e.g. no globals, use x.count
| { ... } instead of x.select { ... }.count). But so many of the
| rules are obsessed with trivial details like the "right" style
| of blocks to use (do vs {}) or "" vs '' for strings. Pointless
| busy work. I think the dumbest is requiring "def (x=true)" over
| "def (x = true)". Seriously, why could that possibly matter??
| hrdwdmrbl wrote:
| Why does it matter when there is auto-fix-on-save? I just
| write whatever, hit ctrl+s and the code is fixed. The result:
| The code is "fixed" based on whatever rule and it doesn't
| cost me a thing. I don't think about it and I don't lift a
| finger.
|
| But I do personally appreciate the tidiness of code-
| consistency.
| bioneuralnet wrote:
| That's my argument - if we collectively care, it should
| happen automatically. Alas, no one else seems bothered by
| the status quo.
| hrdwdmrbl wrote:
| Some of these rules do support autocorrect
| skissane wrote:
| > I think the dumbest is requiring "def (x=true)" over "def
| (x = true)". Seriously, why could that possibly matter??
|
| For Python, I use ruff to autoreformat my code into a
| consistent style. The CI pipeline fails the PR if the style
| is violated it. Fixing it is a one-liner. Actually, if you
| use VSCode's ruff extension, a zero-liner, since it auto-
| formats on save.
|
| For Java, I use Diffplug Spotless for a similar experience.
|
| One advantage of forcing the code to be auto-formatted, is it
| makes diffs cleaner - you eliminate diffs where someone just
| changed the code style, since the code style never changes.
| imoverclocked wrote:
| It's been quite some time since I've used Rubocop but I did fight
| an uphill battle to get it into place. One of the things I had a
| difficult time explaining was that rules subtly interact with
| each other. When one rule makes a change, it might simplify
| something such that another rule can then also make a change.
| Once I enabled enough rules, there were some pretty impressive
| chains that were whittled down to almost nothing... but the same
| application of those rules elsewhere caused hemming and hawing by
| the naysayers.
|
| I think the best thing that these tools give, above all else, is
| a way to settle petty opinions in a team. It's why there is value
| in rules that either conflict with each other or are configurable
| so as to meet the expectations of a given team.
| block_dagger wrote:
| Hopefully rubocop-rails-omakase [1] will pull in stuff like this.
| I've gone from custom Rubocop rules in various projects to just
| using rubocop-rails-omakase, which finally feels like a consensus
| of sorts. I think Standard [2] is harmfully redundant,
| personally.
|
| [1] https://github.com/rails/rubocop-rails-omakase [2]
| https://github.com/standardrb/standard
| caseyohara wrote:
| I'm curious why you think Standard is "harmfully redundant"?
___________________________________________________________________
(page generated 2024-10-30 23:00 UTC)