Hacker News Reader

Comment by mparramon | Hacker News Reader

Following Rubocop's Ruby Style Guide [1] to the dot helps a lot with this, and it's quite easy to enforce using the rubocop gem + a GitHub action

[1] - https://github.com/rubocop-hq/ruby-style-guide

View on HN

I wouldn't really go that far though, as you'll end up with a codebase that the linter likes (and appears clean) but is still an utter nightmare to read because of all the forced indirection. I'm talking about things like: restricting method length to 10 lines, restricting class length to 100 lines, and similar ones that prevent you writing code in a certain way because the preferred approach to writing code is 'out of sight, out of mind'.

Default Rubocop is why you have codebases where code is still complicated, it's just hidden away inside single use modules (concerns) or inside single-use private methods. As far as I'm concerned you just can't defer the architecture of your codebase to a tool like that and I'm sure it teaches more bad habits than good ones.

Instead, decide these things for yourself and keep it in check during code review or the stage before that. Maybe even design rubocops of your own to help. The linter can still do a good job without telling you how to handle complexity.

Very refreshing to see this take and I largely agree. People all too often refer to linters as The Rule rather than The Tool, and forget that a robot will never be able to evaluate the quality of a codebase. That requires human input (though Rubocop is very efficient for people that want to avoid human input--often the root cause of the problem).

That said, I am a fan of single-use private methods and think they have their place, with or without method-length rules.

You can configure rubocop however you want.

If you find the defaults to be not good (which I agree), then simply update the rubocop.yml.

In fairness, ljm was responding to a comment that suggested following the style guide "to the dot".

That was that's exactly the point I was aiming to address, thanks :)

Couldn't agree more. Our Rubocop is FULL of customizations and the odd override too (though there is a case some overrode a rule which caused massively confusing code).

"Single use private methods" is a little triggering to me... not even rubocop's fault. I've seen the likes of this before (single use):

  def redirect_to_home_unless_user_present
    redirect_to :home unless user.present?
  end

Why!?? (that is a rhetorical "why")

That's a horrible usecase for single use private methods, agreed. But I think they're an excellent way to breakdown a complex chunk of code into smaller components, using the method names to describe what they're doing. That requires good naming, though; without good names, the effort is moot.

I think they serve a good purpose once you realise you've stepped out of OOP. You have the idea of a command, or a service, and it does a bunch of procedural things as part of its execution. It only has one public method, so the private methods are a way to describe the steps of the command.

But that's an architectural decision, it's not code style. If rubocop tells you how to write a function then you're going to see nonsense like the example in our parent comment.

> I think they serve a good purpose once you realise you've stepped out of OOP. You have the idea of a command, or a service, and it does a bunch of procedural things as part of its execution. It only has one public method, so the private methods are a way to describe the steps of the command.

It doesn't have to be a step out of OOP, and their usage is not limited to "Single Public Method Objects". Single use methods are just a convenient and clean way to make complicated code easy to digest, OOP or not.

Reply on news.ycombinator.com