3 ms·

I really enjoyed reading this! When Discourse was originally announced, I read this file (quite randomly), and was distressed at the complexity and length (eve

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 http://en.wikipedia.org/wiki/Law_of_Demeter), nor had I heard of Sandi Metz's rules for Rails development (http://gist.io/4567190 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?

city41 14y ago
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.
- jevinskie 14y ago
  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?
- philfreo 14y ago
  Have you seen Docco? http://jashkenas.github.com/docco/ http://jashkenas.github.com/docco/
dogas 14y ago
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.
- octernion 14y ago
  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.)

city41 14y ago

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.

jevinskie 14y ago
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?
philfreo 14y ago
Have you seen Docco? http://jashkenas.github.com/docco/ http://jashkenas.github.com/docco/

dogas 14y ago

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.

octernion 14y ago
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.)