5 ms·

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:/

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 https://github.com/rubocop-hq/ruby-style-guide

ljm 6y ago
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.
- andrewzah 6y ago
  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.
  - sodapopcan 6y ago
    In fairness, ljm was responding to a comment that suggested following the style guide "to the dot".
    - ljm 6y ago
      That was that's exactly the point I was aiming to address, thanks :)
- sodapopcan 6y ago
  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")
  - ysavir 6y ago
    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.
    - ljm 6y ago
      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.
      - ysavir 6y ago
        > 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.
- ysavir 6y ago
  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.

ljm 6y ago

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.

andrewzah 6y ago
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.
- sodapopcan 6y ago
  In fairness, ljm was responding to a comment that suggested following the style guide "to the dot".
  - ljm 6y ago
    That was that's exactly the point I was aiming to address, thanks :)
sodapopcan 6y ago
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")
- ysavir 6y ago
  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.
  - ljm 6y ago
    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.
    - ysavir 6y ago
      > 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.
ysavir 6y ago
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.