What parts of a Ruby-on-Rails application (with reasonably expressive unit tests) should have RDoc? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4开发者_Go百科 years ago.

Improve this question

I'm developing an open-source web application on top of Rails. I'd like to make my code as easy to understand and modify as possible. I'm test-driving my development with unit tests, so much of the code is "documented" through test cases (what each controller action expects as input, what instance variables are set for output, how helpers should be called, what business logic the models incorporate, etc.). And on top of that, Rails' conventions should make a lot of documentation unnecessary where my code conforms to them.

So, where's the balance between having a well-documented Rails application and trying to obey Don't Repeat Yourself? Are there any good blogs or articles with guidance on what (RDoc) documentation is really helpful in a Rails app, and what's just waste?

---

OK, not at all sure this is the right thing, but here's what I decided to do:

First, I thought that another Rails developer would be familiar with at least the intent of all of the code I wrote in the standard models, views, controllers directories. So, I started adding RDoc in other source files. It turns out that I'd built up a fair collection of code in lib/helpers and app/helpers, so started there. I wrote fairly typical function-level documentation for each helper method, focusing on intent and making sure I'd spelled out the things that the method and argument naming was mnemonic for. I didn't describe most of the corner cases, argument interactions, or error checking, leaving those details to a reading of each method's unit tests.

I found that while I was doing this, there were quite a few changes I made to method signatures, rather than having to document having done something stupid. (Have you read Clean Code by @unclebobmartin? I think it's great on all fronts, but especially on naming and self-documentation.) So, in addition to being an RDoc-adding exercise, I ended up spending a significant amount of time on (needed) refactorings--things that hadn't occurred to me in the refactoring pass after I'd first written the code because I didn't have enough distance yet. Perhaps 80% of the time I spent "adding RDoc" went into the code in my "helpers" directories, and the majority of that was refactoring rather than writing. So, even if nobody ever reads the RDoc itself, I think this was a valuable exercise and I'm very happy I spent the time

Next, I turned to my Controllers. I left the default single-line comments matching what scaffolding generates on each controller method as the first line of the RDoc (e.g., "# GET /"). For methods that do just the standard Rails thing, I didn't add any other documentation. I found that the unique things I'd done in my controller methods that were worth documenting had to do with what they return (e.g., data formats other than HTML), what they're for (actions beyond the standard REST model, like those intended to service Ajax requests), and whether they use a non-standard URL format. (This was really documentation of my route configuration, but since config/routes.rb isn't used to generate RDoc....) I didn't describe the behavior of my actions at all, feeling that my automated tests sufficiently covered all of the cases/behaviors someone would need to know. Finally, I added class-level comments mentioning the model class that the controller manipulates, not because people can't guess, but so that there'd be a convenient link in the generated HTML page.

Last, I worked on my models. Again, I didn't document behaviors (business logic), considering my unit tests to be sufficient here. What I did do was remind readers that field definitions are in db/schema.rb (felt silly, but if a developer new to Rails was trying to figure things out, being reminded of the base names for all the magic methods couldn't hurt). I also realized that lots of my models' behaviors were implemented through Rails' declarative helper methods called directly by the model classes (validates_..., belongs_to, etc.). Rather than trying to describe what this stuff accomplishes (after all, the desired model behavior is "described" by the tests), I just put in a reminder to look at the model source. (It's a shame RDoc isn't aware enough of Rails conventions to extract and document these things like it does Ruby constant definitions.)

And that was that. Perhaps a little more RDoc than I needed to write, but I think that it is light enough that it will get maintained as the code evolves, and it doesn't overlap at all with things "expressed" by my unit tests. Hopefully, it has filled the gap between what a Rails developer can infer from convention and what you're only going to figure out from the source. (Although I'm now noticing a growing impulse to pull more pieces from my views into helpers, even though they're not reused and it would mean losing ERB's inline HTML, just so that I can write descriptions for them. Go figure.)

---

My short answer: rdoc your models, since they are truly unique to your application.

But it sounds like you are building a web-application, so the argument could be made that you should rdoc other pieces, too.

---

Document anything that is not crystal clear from reading the code. Self-documenting code is easily achieved with Ruby, but crafty logic needs comments! Try to put yourself in the shoes of a project newbie when deciding if something needs rdoc. Odds are that if you're thinking about whether or not it needs it, it does. Lastly, I wouldn't rely on test sources to provide documentation for your application code. I know that if I jumped on a project and was left scratching my head as to why a model is behaving a certain way I wouldn't run immediately to the unit test for answers.