Comment by octernion | Hacker News Reader

Comment by octernion | Hacker News Reader

Parent Full thread

I really enjoyed reading this!

When Discourse was originally announced, I read this file (quite randomly), and was distressed at the complexity and length (even though I totally understand time constraints and the need to 'get it to work').

I had never heard of the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter), nor had I heard of Sandi Metz's rules for Rails development (http://gist.io/4567190), both of which put in concrete terms some of the lessons I've learned when maintaining Rails applications.

I'd love to see more of these!

Edit: After reading over the pull request, I admit I'm a little confused why the response code was refactored into 'perform_show_response' - this seems like the direct responsibility of this controller method (and isn't common or otherwise misplaced). Is there a reason why you moved it out?

My intent was to make the show method read almost like pseudocode when I was done with it, so the reader could easily see, at a glance, a high-level overview of what was happening with that method.

I tried to make the experience of seeing that code sort of like reading the front page of a newspaper. You see the headlines, but if you want to drill down, you gotta go more in depth. It also allowed me to keep the size of the methods down.

This entire refactor was meant to make the code more readable, which is why I made some of the decisions I made.

Ah, I see what you mean. I've never really thought about how one approaches methods from a structural perspective (especially controller methods).

I suppose for something like the respond_to block, which is shared to pretty much every controller method (and unique to that method, most likely), my thought was that its absence makes the method slightly more confusing for the experienced Rails developer.

So, would you extend this reasoning to every controller method? ('perform_index_response', 'perform_edit_response', etc.)

One idea I've always had in the back of my head but have never pursued was plugins for text editors/IDEs that allow developers to quickly and easily make commentary on the code they are writing, and the end result would be blog posts formatted much like this one.

Have you seen Docco?

http://jashkenas.github.com/docco/

I would love to see that implemented! I wonder if it could be an emacs mode or vim plugin with split views or doxygen-style inline comments?

Reply on news.ycombinator.com