3 ms·
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
by 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 agoAh, 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.)