I did some searching and it looks like YARD is favoured by a lot of the Rails community.
Yep, Yard is still the most popular choice for documenting Ruby code.
For example, it seems silly to provide a docstring for the ApplicationController class.
Agreed; you can safely assume Rails developers will know what this is.
However, leaving things like ApplicationController undocumented causes YARD to list them as such, and display less than 100% coverage.
I wouldn’t worry about getting 100% coverage, since you’ve already made the decision that some things aren’t worth documenting. If you want to double check that you’ve documented everything worthwhile, you can run yard stats --list-undoc to see what’s currently missing documentation.
Does it make sense to provide documentation for simple Rails controllers?
I don’t generally do this, but it might be worthwhile in an engine. A single sentence stating which page or resource the controller is in charge of would suffice. It may also be more useful to just list these controllers and responsibilities out in the README. Far more people will scan README documentation than will dive into documentation for individual modules.
I can’t seem to find any consensus (or even information) on how to document the params hash for Rails controller actions.
Yeah, I’m not sure how you’d do this. Yard doesn’t have tags for this, but you can add custom tags. I don’t think it would be worth it, though. If you’re following conventions, the expected parameters should be obvious.
Is there a way for a private repo have YARD documentation available without having to clone the repo and run yard doc?
You can make a rake task to generate the documentation and push it to S3, which will happily serve static HTML. It may be easiest to have CI run this task, so that your documentation gets updated whenever you merge into master.